ErasureDocs
Security

Security

Product security model. Auth, RBAC, secrets, connectors, evidence limits.

Security

Source of product behaviour: internal security model and API conventions. Aligns with the marketing Security page. Prefer this docs page for implementers.

Why it exists

Erasure holds consent proof, privacy requests, connector credentials, and evidence. Security is part of the product contract.

Architecture assumptions

  • Modular monolith; one Postgres
  • Operators use the console; subjects use public intake / SDK
  • Worker has network access to customer systems you configure

Authentication

ActorMechanism
OperatorHttpOnly session cookie (erasure_session); password scrypt; login uses dummy scrypt for missing users (timing)
SDKPublishable key hash lookup
Rights subjectOTP email; code hashed at rest
Billing webhookProvider HMAC (e.g. Razorpay) when configured

Sessions: opaque tokens, hashed in DB, limited TTL; password change revokes sessions and refreshes cookie.
Browser transport: raw session token is not exposed to JavaScript (HttpOnly). Console uses credentialed requests; CSRF: mutating cookie-authenticated requests require matching Origin/Host. Bearer session tokens may still work for tests/API clients.
Password reset: product supports forgot/reset flow when mailer is configured.
Email verification on register: not required in Closed Beta trusted-signup model.

Password minimum length: 12.

Auth HTTP

See Authentication API.

Authorization (RBAC)

RoleCan
OwnerAll + billing, publishable keys, secret rotation
AdminRead + write (projects, consent, rights, systems, maps)
ViewerRead only

Enforced on platform mutating routes. Non-members get 404 (no org leak); wrong role 403.

Multi-tenancy

Org membership gates org data; project access via org; cases scoped by organizationId; receipts by projectId. Cross-tenant reads must fail closed.

Secrets & encryption

SecretStorage
Passwordsscrypt
Sessions / publishable keysSHA-256 hash
Connector credentialsAES-256-GCM (CONNECTOR_SECRETS_KEY)
Accord webhook signing secretsSame AES-GCM class
OTPHashed at rest; email only

Domain allowlist (SDK)

Per-project host allowlist (Develop → Allowed origins). New projects default allowlist enabled (empty patterns fail closed until you add hosts). When on, SDK config/consent return origin_not_allowed for non-matching origins.

OTP (Rights intake)

  • Expiry, attempt limits, outstanding challenge caps
  • Single-use (mark used before case create)
  • Rate limits IP + email
  • Production: Resend (or configured mailer); demo OTP forbidden in production

Webhooks

  • Accord: HMAC signature header (X-Accord-Signature); SSRF checks; no unsafe redirects
  • Signing secrets encrypted at rest

Connectors

  • SQL identifier allowlist + parameterized values
  • Production TLS required on SQL URLs (unless documented private-network insecure flag)
  • HTTP base URLs SSRF-checked
  • Worker egress should be controlled

Headers

Middleware sets CSP, HSTS (prod), frame deny, nosniff, and related controls.

Rate limits

Auth, register, publish, publishable key create, SDK config/consent, Rights intake: limited.
429 responses include Retry-After and X-RateLimit-* where documented.

Evidence limits

Evidence packages are exportable operational records, not a cryptographically sealed legal WORM archive in Beta. Not a SIEM. Not proof about unconnected systems.

Multi-tenant SaaS vs isolation

Architecture supports multi-tenant orgs in one deploy. For Closed Beta, isolate workers and trust RBAC + network policy.

Migrating environments

  1. Migrate Postgres.
  2. Copy CONNECTOR_SECRETS_KEY or re-enter secrets.
  3. Reconfigure publishable keys (raw keys not recoverable).
  4. Point SDK origin at the new host.

Responsible disclosure

Report vulnerabilities privately to maintainers. Do not use production customer data in tests.

Marketing Security page · API · Production checklist · Troubleshooting