Run your first free audit in five minutes
The free audit answers one question in about five minutes: can a stranger read your database right now, using only what your app already publishes to every visitor?
It needs no account, no connection string and no change to your project. If the answer is yes, the report tells you which tables responded and what to do first.
Run the probe
Open the audit page, paste the URL of your deployed application and start the check. The probe downloads the page and up to eight of its JavaScript bundles, looking for a Supabase project URL and the anon key that client-side apps publish in the bundle by design.
If your app loads its configuration at runtime rather than bundling it, the report says so and provides fields for the project URL and anon key. Paste them from your Supabase dashboard and run the check again; nothing else is required.
Every request the probe makes is read-only. It speaks GET, HEAD and OPTIONS and refuses to send anything else, so the worst outcome is identical to a visitor pressing refresh repeatedly. The check also runs against a wall-clock budget, and the report says so plainly if it ran out before finishing every table.
Read the report
Findings appear ordered by severity. A service_role result means a credential that bypasses every policy is sitting in a public bundle: rotate that key first, then move whatever needed it behind a server route. A table-readable result means rows actually came back to an unauthenticated request; the finding names the exposed columns and a row count, never the values.
Tables that answered with HTTP 200 and an empty array are listed separately as reachable but not leaking. That response is genuinely ambiguous, because Row Level Security filtering every row and an empty table look identical from outside, so it is reported as information rather than raised as a critical finding.
A clean report is informative rather than ceremonial: it means the probe found no readable tables and no exposed keys in the bundles it fetched. It does not certify security, and the page does not pretend otherwise; it means this particular door is shut.
What five minutes does not cover
The probe is external and deliberately shallow. It cannot read your policies, weigh write access, or notice that a policy was rewritten last week. For scheduled checks, drift history and remediation SQL generated from your real columns, connect the project. The free plan includes one connected project with daily scans, and findings and remediation SQL are never withheld on any plan.
RowShield is an independent product and is not affiliated with or endorsed by Supabase; the probe simply exercises the public endpoints a Supabase project already exposes.
Related questions
- Is the free audit really free?
- Yes. The probe runs against the public surface with no account behind it, and connecting one project for daily scans is free as well. Paid plans add projects, scan frequency and alert destinations.
- Did the probe store anything from my tables?
- No. Rows returned to an unauthenticated request are reduced to column names and a count before anything is retained, so the report proves exposure without holding any of your data.
Did this answer your question? If not, tell us what is missing — article corrections go straight to the person who maintains it.