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 Anumati 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.