Controls
The EDFlow controls matrix: authentication and MFA, server-side authorization and projections, token hashing, encryption, rate limits, audit, log redaction, security headers and CSP, supply chain, vulnerability management and penetration testing.
Controls matrix
| Area | Control |
|---|---|
| Staff authentication | Invite-only; passwords of 12+ characters with a strength check and a breached-password list; MFA (TOTP) required in production; optional Microsoft Entra ID (OIDC with PKCE, guest accounts refused); lockout after 5 failures in 15 minutes from unknown devices; idle lock after 15 minutes; 12-hour sessions; fresh sign-in for sensitive actions |
| Patient and family access | 128-bit random card and link tokens in the URL fragment only; a second device needs the date of birth or the first device's approval; staff-assisted sign-in by reverse pairing, so staff never hold a usable credential; at most 5 patient devices per visit and 3 per family link; access ends automatically after departure |
| Authorization | Server-side only: identity is derived on the server, never from client-supplied ids, roles or sites. Each staff function checks a permission at the active site. Cross-site ids return "not found". Every read goes through an allow-listed projection per audience, with tests that forbidden fields are absent |
| Audit before read | A staff member must open a visit (recorded) before reading or acting on it. Board views recorded every 15 minutes |
| Token storage | Tokens, visit codes and API secrets stored only as keyed HMAC hashes; a copy of the database opens nothing |
| Encryption | TLS 1.2+ (1.3 preferred) with HSTS preload; AES-256 at rest with KMS customer-managed keys; phone numbers and MFA secrets encrypted with AES-256-GCM; per-organization KMS keys for integration secrets, with a hospital-held key option |
| Rate limits | Per network, per visit, per account, per app, per endpoint; never a global lockout that would let an attacker lock staff out |
| Audit | Append-only log with a daily hash chain; per-patient access report; monitoring rules; SIEM export |
| Log redaction | The backend logger accepts only allow-listed keys; console is banned by lint; HTTP handlers never log bodies, headers or token paths; parser errors carry positions, not values |
| Notifications | Generic templates only; payload lint in CI |
| Web security | Nonce-based CSP, frame-ancestors 'none', X-Content-Type-Options: nosniff, strict referrer policy, no-store and no-referrer on token routes, no third-party scripts on patient and family pages, self-hosted fonts |
| API security | OWASP API Top 10 controls: site-scoped queries, short-lived tokens, network binding, allow-listed projections, rate limits, SSRF policy for webhooks, strict schemas, no CORS |
| Integration | HMAC or OAuth; replay window; idempotency; prohibited-field tripwire; IP allowlists; per-source keys with rotation overlap |
| Supply chain | Lockfile integrity, dependency audit, secret scanning (including the service's credential prefixes), SBOM, pinned CI actions, signed build artefacts with provenance, two-person production deployments |
| Vulnerability management | Critical vulnerabilities fixed within 72 hours; forced app updates for security fixes |
| Penetration testing | External test of the API, edge, portal and patient web before live; annually and after major changes; summary letter shared |
| Privileged access | No standing vendor access to production data; just-in-time break glass with approval and session recording. See Privileged access |
| Resilience | See Availability and incidents |
Security headers
| Header | Value |
|---|---|
Strict-Transport-Security | 2 years, includeSubDomains, preload |
Content-Security-Policy | Nonce-based scripts, connect-src limited to the backend, frame-ancestors 'none' (the display only for configured origins) |
Referrer-Policy | strict-origin-when-cross-origin; no-referrer on token routes |
Permissions-Policy | Camera only on sign-in and staff scan routes |
Cache-Control | no-store on token routes and API responses |
Verification
Every public backend function has tests for the happy path, an authorization denial and a validation failure, and an authorization matrix is generated from the permission catalogue. Projection tests assert forbidden fields are absent. Storage and log scans run over end-to-end test runs.
Related
Last updated on