Skip to main content
Open Book Clinical/Security/Vulnerability Disclosure Policy

Security

Vulnerability Disclosure Policy

We take the security of OpenBook Clinical seriously. If you believe you have found a security vulnerability, we want to know about it. This policy explains how to report a vulnerability responsibly and what you can expect from us in return.

Acknowledge within

2 business days

Critical fix target

14 calendar days

Aligned with

ACSC guidelines

Section 1

Scope — what is covered

This policy applies to security vulnerabilities in OpenBook Clinical's own infrastructure and code. We welcome reports on any of the following:

✓ In scope

  • openbook-clinical.com.au and all subdomains
  • Supabase-backed API endpoints (/api/*)
  • Authentication and session management
  • Data access controls and Row Level Security (RLS)
  • Client-side injection vulnerabilities (XSS, CSRF)
  • Sensitive data exposure in transit or at rest
  • Broken access control or privilege escalation
  • Security misconfiguration in production

✗ Out of scope

  • Third-party infrastructure (Vercel, Supabase, Stripe, Anthropic)
  • Social engineering attacks against our staff
  • Denial of service (DoS / DDoS) attacks
  • Spam, phishing, or email-based attacks
  • Physical attacks against data centres
  • Findings from automated scans with no proof of exploitability
  • Rate limiting or brute-force on non-sensitive endpoints
  • Self-XSS or vulnerabilities requiring physical device access

If you discover a vulnerability in a third-party service we use (Vercel, Supabase, Stripe), please report it directly to that provider under their own vulnerability disclosure programme.

Section 2

How to report a vulnerability

Please email your report to our security team. Do not post vulnerability details publicly until we have had a chance to investigate and issue a fix.

Report to

security@openbookclinical.com.au

Subject: Responsible Disclosure — [Brief Summary]

Please include in your report:

01

Steps to reproduce

A clear, step-by-step description of how to reproduce the vulnerability. Include any tools, URLs, or request payloads needed.

02

Affected URL or component

The specific endpoint, page, or component where the vulnerability exists. Include the full URL where applicable.

03

Potential impact

Your assessment of what an attacker could achieve by exploiting this vulnerability — e.g. data exfiltration, account takeover, session hijacking.

04

Evidence (optional but helpful)

Screenshots, HTTP request/response logs, or a proof-of-concept that demonstrates the issue. Please do not exfiltrate real user data — use your own test account.

PGP encryption: If you need to send sensitive vulnerability details securely, contact us first at the address above to request our PGP public key. We will provide it promptly.
Section 3

Our commitments to you

When you report a vulnerability to us in good faith, we commit to the following:

  • Acknowledge your report within 2 business days of receipt.
  • Provide you with a unique tracking reference for your report.
  • Investigate the report and keep you informed of progress.
  • Aim to remediate critical vulnerabilities within 14 calendar days, high severity within 30 days.
  • Notify you when the vulnerability is fixed and when we intend to disclose it publicly.
  • Not pursue legal action against researchers who act in good faith and comply with this policy.
  • Credit you in our Hall of Fame (unless you prefer to remain anonymous).
  • Treat all reports as confidential — we will not share your identity without your consent.

Fix timelines are targets, not guarantees. Complex vulnerabilities may take longer to remediate safely. We will always keep you informed if timelines need to change.

Section 4

What we ask of researchers

To qualify for safe harbour and recognition, we ask that researchers comply with the following:

Do not access or exfiltrate user data

If you discover a vulnerability that could expose user data, do not retrieve, copy, or store that data. Demonstrate exploitability using your own test account only.

Do not disrupt production services

Do not conduct testing that could degrade performance or availability for our users. Do not perform load or stress testing. If you need to test at scale, contact us first.

Do not social-engineer our users or staff

Do not attempt to obtain credentials, access, or information through deceptive means. Social engineering is out of scope and will not be treated as good-faith research.

Allow reasonable time for remediation

Please allow us at least 14 calendar days from initial acknowledgement before any public disclosure. We will work with you on coordinated disclosure timing.

Report only to us

Please report vulnerabilities exclusively to us at security@openbookclinical.com.au and do not share them with third parties, broker vulnerability markets, or publish publicly before coordinated disclosure.

Section 5

Safe harbour statement

OpenBook Clinical supports responsible security research. If you conduct security research in good faith, in accordance with this policy, we will not:

  • Initiate legal action against you under the Copyright Act 1968, Criminal Code Act 1995, or equivalent legislation
  • File a complaint with law enforcement regarding your research activities
  • Pursue civil claims arising from your research activity
  • Take action that would unfairly penalise you for conducting good-faith security research

Important caveat

This safe harbour applies only to research conducted in accordance with this policy. It does not apply to activities that go beyond the scope of good-faith research, including but not limited to: deliberate exfiltration of user data, disruption to production services, social engineering, or disclosure to third parties before coordinated disclosure.

This policy is modelled on the Australian Cyber Security Centre (ACSC) Vulnerability Disclosure Policy framework. We are committed to acting in good faith with researchers who act in good faith with us.

Section 6

Recognition

We genuinely appreciate the effort researchers put into identifying and responsibly disclosing security vulnerabilities. As a token of our appreciation:

Hall of Fame

With your consent, we list researchers who report valid vulnerabilities in our Security Hall of Fame. Your name, the date of your report, and a brief description of the issue (without sensitive technical detail) will be included.

View Hall of Fame →

Anonymity

If you prefer to remain anonymous, we will always respect that. Just let us know in your initial report and we will acknowledge your contribution without disclosing your identity.

Get in touch

Questions about this policy?

If you have questions about this policy or are unsure whether your planned research is in scope, please reach out before you begin testing. We would rather answer a question than investigate an unintended incident.

Last reviewed: July 2025. This policy may be updated periodically to reflect changes in our practices or legal obligations.