OpenBook Clinical Security White Paper

The application layer runs on Vercel serverless functions. There are no persistent application servers, no long-running processes, and no server-side ports exposed to the internet. This significantly reduces the attack surface compared to traditional server-based architectures — each function invocation is ephemeral and stateless.

OpenBook Clinical does not operate any self-managed servers, virtual machines, or on-premises infrastructure. The entire stack runs on managed cloud services (Vercel, AWS via Supabase), which means OS patching, hardware security, and physical data centre controls are handled by our providers under their respective certifications.

All communications between the client (browser) and the Vercel edge network use TLS 1.3. Vercel enforces HTTPS-only connections with HSTS (HTTP Strict Transport Security) preloading. TLS 1.0 and 1.1 are disabled. TLS 1.2 is supported for legacy client compatibility where required.

All API calls between Vercel serverless functions and Supabase, Anthropic, Stripe, and Postmark use TLS-encrypted connections over the public internet. Service credentials are never transmitted in plaintext.

All data stored in Supabase (Postgres database, Auth records, Storage files) is encrypted at rest using AES-256, managed by AWS Key Management Service (AWS KMS). Encryption keys are managed by AWS and rotated automatically. OpenBook Clinical does not manage encryption keys directly.

All API keys, database connection strings, and service credentials are stored as environment variables in the Vercel deployment platform. They are never committed to version control, never logged, and never exposed in client-side code. The Supabase service role key (which bypasses RLS) is used only in server-side serverless functions — it is never sent to the browser.

User authentication is handled by Supabase Auth, which implements the OAuth 2.0 PKCE (Proof Key for Code Exchange) flow. PKCE prevents authorisation code interception attacks and is the recommended flow for single-page applications. Session tokens (JWTs) are short-lived and automatically refreshed.

Multi-factor authentication (MFA/TOTP) is available to all users via the account settings panel. Institutional accounts with elevated access requirements are encouraged to enforce MFA as a condition of access.

Every table in the Supabase Postgres database has Row-Level Security policies enforced at the database level. This means that even if an application-layer bug produced an incorrect query, the database engine itself would prevent any user from accessing another user's data. RLS policies are deployed and version-controlled as part of the application codebase.

Supabase provides two authentication tokens: the public anon key (safe to expose in browser code, restricted by RLS) and the service role key (bypasses RLS, used only for server-side operations). The service role key is stored only in Vercel environment variables and is never accessible from client-side code.

JWT access tokens expire after one hour. Refresh tokens are rotated on use and expire after 30 days of inactivity. Sessions can be revoked instantly via the account security settings or via an administrative action for institutional accounts.

The following security headers are applied to all HTTP responses from the Next.js application:

Vercel's global edge network provides layer 3/4 DDoS mitigation as a platform default. API rate limiting is enforced at the application layer on all public endpoints. Aggressive or anomalous traffic patterns trigger automatic throttling.

The serverless architecture means there are no persistent server processes listening on network ports. There is no SSH access to production, no open database ports on the public internet, and no server-side administrative interfaces exposed outside the Vercel and Supabase management planes.

OpenBook Clinical does not collect, store, or process patient personal information. Users are instructed not to include patient names, dates of birth, Medicare numbers, or other patient identifiers in their search queries. Technical controls including PII detection patterns are applied to warn users when potentially identifiable information is detected in query text.

Before a search query is sent to the Anthropic API, the application strips authentication context. The request to Anthropic contains only the clinical query text and a system prompt — no user identifiers, account data, or session tokens are included. Anthropic processes these queries under a zero-data-retention agreement and does not associate queries with OpenBook Clinical accounts.

OpenBook Clinical operates a responsible vulnerability disclosure programme. Security researchers and users who discover potential vulnerabilities are encouraged to report them via our Vulnerability Disclosure Policy or by emailing openbookclinical@gmail.com with subject line “Responsible Disclosure”. We acknowledge receipt within 1 business day and commit to keeping reporters informed of remediation progress.

npm dependencies are monitored for known vulnerabilities via automated tooling (GitHub Dependabot). Security advisories trigger priority patch reviews. Critical vulnerabilities in production dependencies are addressed within 72 hours of notification where a patch is available.

The serverless model means OpenBook Clinical has no traditional OS footprint to patch. Vercel manages the runtime environment (Node.js) and handles underlying OS security. Supabase manages the Postgres database engine on AWS-managed infrastructure.

Our Essential Eight maturity posture is documented at /security/essential-eight. The serverless, no-persistent-server architecture natively satisfies several Essential Eight controls (patch OS, restrict admin privileges, disable untrusted macros).

Under the Privacy Act 1988 (Cth) Notifiable Data Breach scheme, if OpenBook Clinical becomes aware of an eligible data breach — defined as unauthorised access or disclosure of personal information likely to result in serious harm — we are obligated to:

• Notify the Office of the Australian Information Commissioner (OAIC) as soon as practicable
• Notify affected individuals as soon as practicable
• Complete notification within 30 days of becoming aware of the breach

For institutional subscribers with a signed DPA, we also commit to notifying the institutional Controller within 72 hours of becoming aware of any breach affecting their users' data, in accordance with the DPA breach notification clause.

Security incidents and suspected breaches should be reported to openbookclinical@gmail.com. This address is monitored continuously and triaged within 4 hours on business days.

All sub-processors (Supabase, Vercel, Anthropic, Stripe, Postmark) are selected based on: independent security certifications (SOC 2 Type II or PCI DSS); data processing agreements (DPAs) that impose equivalent obligations to those owed to our users; and publicly documented data handling practices.

Each sub-processor is bound by a data processing agreement requiring them to: process data only on our documented instructions; notify us of security incidents affecting our data within 72 hours; impose equivalent obligations on their own sub-processors; and delete our data upon termination.

We maintain a current sub-processor list at /governance/sub-processors. Institutional subscribers are notified of any sub-processor additions or replacements with not less than 30 days' notice, giving the opportunity to object.

Sub-processor certifications and DPAs are reviewed annually. Where a sub-processor's security posture materially changes, we assess the impact and update our governance documentation accordingly.

OpenBook Clinical is committed to compliance with the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs). Our full Privacy Policy is available at /privacy. Data subject access, correction, and deletion requests are processed within 30 days of receipt.

When an OpenBook Clinical account is created, all associated data (profile information, search queries, CPD records) is written to Supabase Postgres, which runs on AWS infrastructure in the ap-southeast-2 region (Sydney). Supabase Storage (for any uploaded files) uses the same region. Supabase Auth session data is similarly hosted in ap-southeast-2.

The only data that leaves Australia is the text content of search queries, which is sent to Anthropic's API (hosted in the United States) for AI synthesis. This text is:

• Stripped of all user identifiers before transmission — Anthropic receives only the clinical query text
• Processed under a zero-data-retention agreement — Anthropic does not store the query or response after processing
• Never used to train Anthropic's AI models
• Never associated by Anthropic with any OpenBook Clinical user account

Payment card data is processed by Stripe. OpenBook Clinical never receives or stores card numbers, CVVs, or bank account details. Stripe stores a payment token in its own data centres (USA/EU under PCI DSS Level 1 compliance). The token stored by Stripe is used only to initiate future charges at the user's direction.

Account notification emails (signup confirmation, billing receipts, security alerts) are sent via Postmark, a US-based SMTP provider. The email recipient address (user's email) and message content is transmitted to Postmark servers for delivery. Postmark retains email logs for 45 days under its standard terms.