Security

Traffic between browsers, our API and third-party services uses TLS, and the site sends HSTS with includeSubDomains and preload so a browser will not fall back to plain HTTP.

Data is encrypted at rest with AES-256 using Microsoft-managed keys. That covers the production PostgreSQL database, its automated backups, and blob storage for call recordings, faxes and invoices. Application-level secrets get their own protection: TOTP second-factor secrets are stored as AES-256-GCM ciphertext and are never written in plaintext, and EMR provider credentials are held in Azure Key Vault rather than in the database.

Staff and dashboard endpoints authenticate the caller themselves; none of them relies on a router-level guard. Each query is then scoped to the account named in that caller's token, in application code, so naming another clinic's record returns the same answer as naming a record that does not exist.

Some patient-facing paths have to work without a login — a booking page or an intake form a patient opens from a link. Those are authorized by the link itself, which is specific to one clinic and one record, and the request is scoped to that record rather than to any account. They cannot read or write another patient's data: only the fields the flow needs are projected, and nothing ownership-shaped in the request body is trusted. Both models are covered by a regression suite that fails the build if a scoping predicate is dropped.

Multi-tenant isolation is not delegated to database row-level security: the API connects over a single privileged database role, so row-level policies would not constrain it. Isolation is enforced in the query layer instead, and a table can only be exposed to the generic data API after it has been classified and given an explicit owner predicate.

Administrative access is limited to a named allowlist of user accounts. An email address never grants administrative rights. Dashboard accounts can enable TOTP two-factor authentication with single-use recovery codes, and a clinic can restrict dashboard sign-in to an IP allowlist.

Access to patient records through the dashboard is written to an audit log. The log is append-only: a database trigger rejects updates to existing rows, and a delete floor prevents history from being trimmed away.

The record covers the dashboard's data API and the function endpoints it calls. It is not a log of every packet the platform moves, and we describe it by what it covers rather than as a complete trail.

Clinics can read and export their own access log from Settings → Security. Each entry records who accessed what, when, and from which IP address, and reading the log is itself audited. The clinic-facing projection deliberately omits stored request and response payloads, so the log records the event without carrying message or document contents. Each clinic's log states its own start date rather than implying it is a complete history of the platform.

FrontDeskClinic runs on Microsoft Azure: Azure Container Apps for the API and edge functions, Azure Static Web Apps for the web app, and Azure Database for PostgreSQL for application data. Production runs in the Central US region of the United States.

The production database has automated backups and point-in-time restore enabled.

The web app sets the following headers on every response. They are configured in one place and shipped with the build, so every route gets them.

Content-Security-Policy

Scripts run only from our own origin, Stripe, and an explicit hash/allowlist of trusted vendors — script-src carries no unsafe-inline. Object embedding is disabled, and frame-ancestors is none.

Strict-Transport-Security

HTTPS is enforced with a one-year max-age, includeSubDomains and preload.

X-Frame-Options / COOP / CORP

The app cannot be framed by another site, and cross-origin opener and resource policies are same-origin.

X-Content-Type-Options / Referrer-Policy

MIME sniffing is disabled, and referrers are limited to the origin for cross-site navigation.

Permissions-Policy

Camera and geolocation are denied to every page; microphone is limited to our own origin for browser calling.

One deliberate exception: style-src keeps 'unsafe-inline' because several UI libraries inject styles at runtime. Script execution does not — it is hash- and allowlist-based, which is where the meaningful cross-site scripting protection lives.

Card payments are processed by Stripe. Card details are entered into Stripe-hosted payment fields and never reach FrontDeskClinic's servers, so we do not receive or store full card numbers. Our systems hold only the identifiers Stripe returns for a saved payment method or a charge.