What you connect

DBAudit asks for a little more than some scanners, and that is deliberate. The inputs below are the realistic minimum for an audit that reflects how your database actually behaves under real users, rather than a surface check that only confirms a policy exists. A scan is only as honest as the access it is given to test, so we ask for what a real audit needs and nothing beyond it.

For Supabase, DBAudit connects with your project URL, the public anon (publishable) key, and a signed-in test login - either an email and password for a test account, or a JWT. You can optionally paste a read-only schema export, which is a select-only introspection query you run yourself in the Supabase SQL editor and which needs no keys, so DBAudit can see every table, policy, and function for full coverage. DBAudit does not accept your service_role or admin key.

For Firebase, you connect using your project's public web configuration, the same values your client app already ships.

Which roles it tests as

• Anonymous (public). What anyone holding your public key can reach.
• A signed-in user. Required. What a logged-in account can read and write.
• A second signed-in user.Optional. Lets DBAudit prove whether one account can read or modify another account's rows, instead of only checking whether RLS is switched on.

DBAudit never tests using a service_role or admin context, because that key bypasses your policies and would hide the exact problems a scan is meant to find.

What it checks on Supabase

• Tables with RLS disabled, and policies that resolve to always-true or overly broad access.
• Cross-account reads and writes, so a logged-in user cannot reach another user's data.
• A publicly enumerable schema, where the anon key can list every table, column, and RPC.
• RPCs and SECURITY DEFINER functions that a normal user can call.
• Exposed or leaked secrets in your data, with optional live verification of keys that are found.
• Sensitive columns - passwords, tokens, PII, payment fields - reachable by the wrong actor.
• Storage buckets, and JWT or key role and expiry issues.

What it checks on Firebase

• Firestore and Realtime Database reads and writes exposed to unauthenticated and authenticated users.
• Storage bucket listing, read, and write access.
• Overly broad security rules, including recursive wildcards, create and update divergence, and phantom ownership checks.
• App Check, anonymous sign-in, open sign-up, email enumeration, and API key restriction.

What happens to your data

• Read and write checks are non-destructive by default. Write probes are sent inside a rollback-guarded transaction, so no rows are mutated.
• Destructive penetration testing is opt-in, guarded, and intended for staging or development - never on by default.
• Sensitive inputs are encrypted at rest with AES-256-GCM, never persisted in plaintext, and discarded once the scan completes or fails.
• We retain scan metadata and the resulting report so your dashboard history works.

What you get

Findings ranked by severity, from critical to informational, each with a specific fix. You also get personalized, agent-ready remediation instructions and a full technical report you can export as JSON.