Supabase
Supabase RLS Exposure Checker
See which of your Supabase tables are readable without logging in.
Supabase dashboard → Project Settings → API. The anon key is meant to be public - this tool only sends read requests it already allows. Only test projects you own.
About this tool
Find out which of your Supabase tables are readable without logging in. Enter your project URL and anon key, and this tool probes your database's REST API directly from your browser, flagging every table left exposed by a missing or permissive Row-Level Security policy.
Frequently asked questions
- Is my data or key sent to your servers?
- No. Every request goes directly from your browser to your own Supabase project - your URL, key, and the results never touch VibeSecurely's servers. The tool only reads counts to tell whether a table is accessible; it never displays or stores the contents of your rows.
- What does 'exposed' actually mean here?
- It means an anonymous request - using only the public anon key that ships in your app's JavaScript - could read rows from that table. That happens when Row-Level Security is off, or a policy is too permissive. Anyone who opens your site has that key, so an exposed table is effectively public.
- Why does it only check reads, not writes?
- Because testing whether a table is writable would mean inserting or modifying data in your database, which this tool will never do. It performs read-only checks. A table can still be exposed to writes even when no rows are readable, so treat a clean result as reassuring, not a full guarantee.
- Why won't it accept my service_role key?
- The service_role key is a secret that bypasses Row-Level Security entirely, so it would report every table as readable and tell you nothing useful - and it should never be pasted into a browser tool. Use the anon (public) key, which is the one your front-end actually ships with.
- A table shows 'No rows' - am I safe?
- It means no rows were returned to an anonymous request, which usually means RLS is doing its job or the table is simply empty. Those two are hard to tell apart from the outside, so if a table is empty today, re-check it once it holds real data. For a definitive answer, a human pentest verifies your policies the way an attacker would.