Is your Supabase database exposed?
Supabase is a great backend, and it is secure â when it's configured. The problem is that the one setting that keeps strangers out of your database is easy to skip, and nothing warns you when it's missing. Your app runs fine either way. Here's the risk, what our scans found, and how to check yours in seconds.
Check your Supabase app now
Paste your app's URL. The free scan checks from the outside whether your database returns data without a login, and whether a secret key is exposed. No signup, nothing changed.
Only scan apps you own or have permission for.The one setting that matters: Row Level Security
Every Supabase project ships with two keys. The anon key is meant to be public â it lives in your frontend by design. The service_role key is the secret one; it bypasses every rule and must never leave your server. The anon key is only safe under one condition: Row Level Security (RLS) is switched on, with policies that say who can read what.
With RLS off, that public anon key can read every row of every table. Anyone can copy it from your app's JavaScript, call the Supabase REST API directly, and pull your whole database â users, emails, everything. No login, no exploit, just the public key you shipped on purpose. That's the single most common serious Supabase mistake, and it's the reason "my anon key is visible" panics people who are actually fine, while people who are genuinely exposed have no idea.
We scanned 65,103 Supabase-backed apps. The good news: most had RLS configured and were locked down. The catch â we still found hundreds returning data or leaking a secret key to anyone. A single missing policy is all it takes, and you can't tell from the outside whether you're in the safe group without checking.
Based on Supabase-backed apps we could reach and scan passively (read-only) from the outside, as of September 2026. Aggregate figures only; no individual app is identified.- High / critical 389 · 62%
- Medium 18 · 3%
- Low 223 · 35%
Severity of the apps we flagged, grouped by their most serious issue (critical counted as high). Passive, read-only scans of publicly-reachable apps, September 2026.
What can go wrong in a Supabase app
RLS off → database readable by the public key
The big one. Tables without Row Level Security return all their rows to the anon key. Full read access to your users' data, no login required.
service_role key in the frontend
The master key. If the secret service_role key ends up in your app's code, anyone can read, edit or delete your entire database â RLS or not. Rarer, but total.
Weak or overly permissive policies
RLS is on, but a policy is too loose â letting a logged-in user read rows that belong to someone else.
Missing browser protections
Security headers that harden the app itself. Minor, but worth closing once the database is locked down.
Seeing your Supabase anon key in the browser is normal and safe â as long as RLS is on. The dangerous key is service_role. We explain how to tell them apart in Exposed Supabase keys: anon vs service_role.
How to check your Supabase app
- In the Supabase dashboard, confirm RLS is enabled on every table with user or private data, each with explicit policies.
- Make sure only the
anonkey is anywhere near your frontend â theservice_rolekey must be server-side only. - Or run the free scan below, which checks from the outside whether your database answers without a login and whether a secret key is exposed.
Is your database locked down?
Find out in about 10 seconds. Free, no signup, read-only.
Only scan apps you own or have permission for.What to do if you find something
- Turn on Row Level Security on every table, and write policies for who can read and write each one. This is the fix for the most common issue.
- Rotate any exposed
service_rolekey immediately and move it server-side â treat the old one as compromised. - Tighten loose policies so users can only reach their own rows.
- Re-scan to confirm your database no longer returns data without a login.
Is Supabase safe to use?
Yes. Supabase is secure by design â the responsibility it hands you is access control, and that's a setting, not a flaw. Turn on Row Level Security, keep the service_role key on your server, and your database is locked down. The scan above tells you, in seconds, whether you're already there.