Skip to main content
Security posture

The data we're protecting deserves to be protected.

We're a privacy service. If we don't treat your data better than the brokers we remove you from, we don't deserve to exist. Here's how we do it.

Encryption at rest

Design target: encrypt all PII at rest with AES-256 in the production Supabase deployment. Pilot data today is held in ephemeral memory and hard-deleted within 24h.

Encryption in transit

All connections to our service require TLS 1.2 or higher. Card details are entered directly into Stripe-controlled fields and never reach our servers.

Row-level isolation

Every database query is scoped via Supabase RLS to the requesting user’s id. There is no admin override that returns another customer’s data — auditable in our open schema.

Two-factor authentication

Two-factor authentication is on the launch checklist; the auth flow is wired through Supabase Auth which supports TOTP and recovery codes natively.

Minimal third parties

Only the specific data broker we’re opting you out of receives your identifiers (and only the fields it requires). Telemetry vendors get zero PII — we use server-side scrubbing on Sentry + PostHog.

Compliance roadmap

SOC 2 planned pre-launch; Type II will follow. CCPA / CPRA authorized-agent flow lives in the product itself. Penetration testing scheduled before public launch.

Reporting a vulnerability

If you've found a security issue, please email security@databrokerremover.com. We respond within one business day, acknowledge within three, and credit researchers who follow responsible-disclosure norms.

In scope: our production domains, our mobile-web pages, the customer + partner dashboards, the dev mock APIs (yes — we want to know if they leak too).

Not in scope: the data broker websites we scan (those belong to their respective operators — please report to them directly), or user-supplied content that doesn't expose other users.

See our Privacy Policy for the legal framing and our retention rules.