Frequently asked questions

Most tools confirm that a Row Level Security policy exists. They don't log in as two different users and try to read each other's data. DeployWarden runs the actual behavioral test: it creates/uses two test accounts and tries to cross the boundary. Existence is not enforcement.

The free scan is passive and read-only. It fetches your pages and JavaScript bundles and probes a few common leak paths (like /.env). It makes no attempt to write data or log in, and it's rate-limited. We still recommend only scanning apps you're involved with.

Active tests attempt real reads and writes. We will never do that against an app you haven't proven you control. You verify by adding a DNS TXT record or hosting a token file at /.well-known/deploywarden.txt. You also tick a consent checkbox authorizing the tests.

Your app's public URL, your Supabase anon key (we can usually auto-detect it), the tables you want tested, and two test accounts (email + password) that we can log in with. The test accounts let us attempt cross-user access the way a real attacker would.

Every active write is a clearly-labeled test row, scoped to the tables you provide, and cleaned up afterward. We never modify your real users' data. If a write unexpectedly succeeds where it shouldn't, that's itself a finding — and we stop.

Cross-user reads and writes (can user A touch user B's rows?), anonymous writes with just the anon key, public storage buckets, whether your service_role key leaked into client code, and a basic Stripe trust-boundary heuristic.

A plain-English report with a severity score, plus copy-paste fix prompts tuned for Lovable, Bolt, and Cursor. It's emailed to you and saved to your report link. One rescan is included so you can confirm your fixes worked.

We store what's needed to run and reproduce the check, protected server-side, and we don't expose it in the browser. After you've fixed issues, rotate your test-account passwords as a best practice. See our Privacy page.