Security
Security model
How Erasure protects operator access, subject flows, connector credentials, and operational proof. Product truth only, no invented certifications.
Runtime
Subjects
SDK · OTP · keys
App
Console · API
Worker
Jobs → systems
↓ Postgres (single database)
Architecture
- Erasure is a modular monolith: one application deploy, one PostgreSQL database, shared auth, tenancy, and billing.
- Operators use the console. End subjects use the browser SDK and public rights intake, not the operator console.
- A separate worker process runs durable jobs (for example rights deletion). Without a worker, jobs remain pending.
Data flow
- Consent: published configuration is loaded by the SDK via publishable keys; receipts are stored for the project; optional project webhooks notify your systems.
- Rights: subjects complete OTP intake (or operators create requests); verified cases can start; the worker executes against connected systems using Data Maps for SQL.
- Evidence packages for consent publish and rights outcomes are assembled on read from domain records, not a separate sealed archive product.
Authentication
- Operators: password (scrypt) and opaque session tokens. Session tokens are stored hashed server-side with a limited TTL; password change revokes sessions.
- Closed Beta note: the operator token is currently held in browser localStorage. XSS is treated as critical; CSP is enforced. HttpOnly cookie sessions are planned, not shipped.
- SDK: publishable keys (pk_live_…) looked up by hash. Rights subjects: email OTP with hashed codes, expiry, attempt limits, and rate limits.
- Billing webhooks (when configured): HMAC verification on provider signatures.
Authorization (RBAC)
- Owner: full access including billing, publishable key create/revoke, and secret rotation.
- Admin: read and write across projects, consent, rights, systems, and maps.
- Viewer: read only.
- Non-members receive 404 on org data (no existence leak). Wrong role receives 403.
Secrets and encryption
- Passwords: scrypt.
- Sessions and publishable keys: SHA-256 hashes at rest (raw secrets shown once where applicable).
- Connector credentials and Accord webhook signing secrets: AES-256-GCM with CONNECTOR_SECRETS_KEY.
- OTP codes: hashed at rest; delivered by email in production.
Systems, workers, and outbound calls
- SQL connectors use identifier allowlists and parameterized values. Production SQL URLs require TLS unless an explicit insecure flag is set for private networks.
- HTTP and webhook targets are SSRF-checked; redirects are not followed for unsafe targets.
- The worker must reach customer systems you configure. Control egress on your network.
- Supported connector types today: PostgreSQL, MySQL, HTTP API, Webhook.
Operational evidence
- Evidence is an exportable package (JSON, CSV, report) for consent publish and rights deletion outcomes.
- It is not marketed as a cryptographically sealed legal WORM archive in Beta.
- Activity timelines in the console are separate from portable Evidence packages.
Deployment model
- Self-host or cloud via DATABASE_URL and standard process split: web/API + worker.
- Health and readiness endpoints support operations.
- Multi-region active-active is not a default product claim.
- Backups: depend on your Postgres provider and operational practice. Erasure does not replace database backup policy.
Responsible disclosure
Report security issues privately to the maintainers. Do not test against production customer data. A public security contact may be published separately; until then, use your established Erasure contact channel.