Supabase RLS check
Check if your Supabase Row Level Security is protecting your data
Supabase ships your anon key in the page. If Row Level Security is off, or a table has no policy, that key can read every row. This is the single most common leak in vibe-coded apps.
A sample of what you might see
Row Level Security is off on this table, so anyone with the public key (which ships in your app) can read it.
{ "email": "•••@•••.com", "role": "admin" }Illustrative, redacted. We never store your data.
The scan uses your app's own published anon key to check, from the outside, which tables are readable. It never logs in and never writes.
JavaScript and TypeScript apps today. The scan is passive and outside-in. How the scanner stays safe.
Questions
How do you check RLS without logging in?
We use your app's own published anon key, the same one your app ships to every browser, and try to read tables from the outside. If a table returns rows, RLS is not protecting it.
Can you prove who can read whose data?
The free scan checks anon access. To prove access control between real users (one user reading another's data), the deeper authenticated check logs in as two test users you authorize.
Which check do I need?
Check my live app
Scan a deployed URL for what it leaks to any visitor: exposed keys, open databases, reachable files.
Free instant scan →
Check my repo / CI hygiene
Review your GitHub Actions and repository config for security gaps in how you build and ship.
Repo & CI check →
Get it fixed
We verify the issues, fix them, and prove the fix in a reviewable pull request.
See packages →