> ## Documentation Index
> Fetch the complete documentation index at: https://docs.denialbase.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Security

> Encryption, access control, audit logging and how we build.

## Encryption

* **In transit**: the app and API only answer over HTTPS, with HTTP Strict Transport Security (one year, including
  subdomains).
* **In the database**: sensitive fields are encrypted by the application before they're stored (Active Record
  encryption): patient names, dates of birth and contact details, claim details, diagnosis codes, document text,
  notes, report contents, the claim numbers you send through the API and API key hashes. The encryption keys are kept apart from the
  database.

## Security headers

API responses refuse to be framed (`X-Frame-Options: DENY`), turn off content-type sniffing, send a strict referrer
policy (`strict-origin-when-cross-origin`) and a restrictive permissions policy.

## Access control

* **Roles**: in a practice, owners and admins manage; viewers can only look. See
  [Your team](/guides/getting-started#your-team).
* **Every request is authorized** against who may see what; a practice sees only its own data.
* **Sign-in**: passwords of at least 12 characters with mixed characters; accounts lock for an hour after 5 failed
  attempts. Two-step verification with an authenticator app, passkeys, magic links, Google sign-in for existing
  accounts, and single sign-on with SAML 2.0 or OpenID Connect.
* **Practice rules**: each practice chooses which sign-in methods its team may use, can require two-step
  verification and can require single sign-on for its email domain.
* **No self sign-up**: accounts exist only by invitation.
* **Rate limits** on sign-in, verification and the claims API.

## Patients

* A patient's link shows nothing about their claim until they confirm their date of birth. After 5 wrong tries,
  the link locks for 15 minutes.
* Links in emails and texts expire, and opening one always asks for the date of birth again.
* Patients sign their authorization themselves and can revoke it any time from their case page.

## Audit logging

* **Access to patient data** (viewing, sending, downloading, signing, changes to settings) is written to a HIPAA
  audit log, with who, what and when, never the patient data itself.
* **Security events** (sign-ins, failures, lockouts, two-step changes) go to a separate security log.
* Both are kept for **six years**.

## Error reports

Errors are reported to our monitoring service with patient data scrubbed out before they leave our servers.
When an error happens in the browser, a replay may be recorded with all text, inputs and media masked.

## How we build

* Every change runs the full test suite before it ships.
* Automated checks on every change: static security analysis of the application code (Brakeman), known
  vulnerabilities in our dependencies (bundler-audit, npm audit) and dependency license checks.
* Production configuration is kept as code and reviewed like code.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.