Free database check · Supabase
Is your Supabase database readable without a login?
The most common serious issue in a fast-built Supabase app is a table anyone can read with the public key that ships in your front-end. This free, read-only check tests for exactly that.
The free Surface Check now runs this automatically when it detects a Supabase or Firebase backend in your front-end, with no key to paste. Use this page for a manual, Supabase-specific check, for example a project it couldn’t detect, or a table with an unusual name.
Paste your anon (public) key only, never your service_role or secret key.
The anon key is the one that already ships in your app’s front-end, so it is safe to share. If you paste a service_role or secret key by mistake, we refuse it and tell you. The check is read-only: it checks your tables and tests which are readable without a login. It never writes or deletes, never reads the contents of your data, and never stores your key.
How the check works
It uses the same public API your own app uses, and does nothing your app couldn’t already do with the key in its front-end.
Finds your tables
It reads your project’s table list where the key allows it, and otherwise checks a list of common table names, since newer Supabase keys don’t expose the full list.
Tests read access
For each one, a read-only request checks whether it returns rows to an anonymous caller, and how many, without reading the contents.
Shows the gaps
Any table readable without a login is flagged by severity, with the fix: enable Row Level Security and a policy that limits who sees what.
Want the outside view too? Also run the free external Surface Check (headers, TLS, email spoofing, and secrets leaked into your front-end).
Supabase database check FAQs
Is it safe to paste my anon key?
Yes. The anon (or publishable) key is public by design: it already ships in your app's front-end for every visitor to see, so pasting it here exposes nothing new. We use it only to make read-only requests and we never store or log it. If you paste a service_role or secret key by mistake, we refuse it and tell you.
Does the check read or change my data?
No. It is read-only and it never reads your rows' contents. It works out which tables to check (from your project's table list where the key allows it, otherwise from a list of common table names), then asks each one only whether it is readable and how many rows it holds (a count), using an HTTP HEAD request. It never writes, updates or deletes anything.
What does 'readable without logging in' mean?
Supabase controls table access with Row Level Security (RLS). If a table has RLS off, or a policy that is too permissive, the public anon key that ships in your front-end can read it with no login. That is the single most common serious issue in apps built quickly on Supabase, and this check finds it from the outside using nothing but your public key.
What if it can't check my tables, or finds nothing?
Newer Supabase projects don't let a public key list the full table set, so we check a list of common table names instead. If none of those are readable, that's reassuring but not a full guarantee: a table with a custom name wouldn't be in the list, which we say plainly. And if the project refuses the key entirely, that's usually a good sign (a locked-down project blocks the public key), though it can also mean the key or URL wasn't quite right. Either way we never guess; we tell you exactly what we saw.
Is this a full security review?
No. This tests which tables your anon key can read. It does not test writes, storage buckets, edge functions, or the access-control logic inside your application, where other serious issues live. A full Secvura review covers all of that by hand, at a fixed £1,200 with a report in one to two weeks.