We hit every table we can find with the anon key and count the rows that come back. If we get data, you have a problem.
Public buckets let anyone list and download files. We walk your buckets and flag the open ones.
We scan your shipped JS bundles for Supabase keys. Anon keys in client code are normal. Service role keys are not.
Edge functions and RPCs that run without auth can be abused. We test the ones we spot in your app's requests.
Can user A read user B's rows? We test the usual IDOR tricks on tables that look user-scoped.
We check for open email signups, missing email confirmation, and OAuth settings that are too loose.
No. We work entirely from the outside, with nothing but what's already public. Same tools an attacker has. No key, no account, no access to your project.
No. We only make read-only requests. We never write, update, or delete anything in your project.
Not by itself. Supabase expects it. The key is public by nature. The risk shows up when RLS is missing, because then the anon key becomes a master read key for your whole database.
Turn on RLS for the table and add policies that scope rows to the logged-in user. Usually three lines of SQL. Get a copy-paste fix prompt you can drop straight into Cursor or Claude Code.
This tool focuses on Supabase only: RLS, storage, RPCs, and leaked keys. For a broader scan that includes API cost exposure, rate limiting gaps, and endpoint fuzzing, try the full LaunchGuard scan.
Paste your app URL and we'll poke at your Supabase project from the outside, no service role key needed. RLS gaps, public tables, leaky storage buckets. You'll see exactly what a stranger can reach.