Reeve Is your Supabase app safe?
Supabase is the database and backend behind a huge share of vibe-coded apps. It's powerful and secure when it's set up right — but a couple of settings decide whether your data is private or open to the world, and they're easy to miss.
Reeve checks the ones that matter from the outside, for free, and explains anything it finds in plain English. No install, no access to your project — we only look at what's already reachable, and we never read your actual data.
Paste your app's link. About 20 seconds. See your grade with no signup.
What can actually go wrong with Supabase
None of these mean you did something wrong — they're the usual gaps when you're moving fast. Here's what's worth checking:
Row Level Security (RLS) turned off
RLS is Supabase's rule for who can read or change each row of a table. With the public "anon" key — which is meant to be in your app — anyone can query your database directly. RLS is what stops them from seeing rows that aren't theirs. If it's off, a table can be fully readable, or even editable, by anyone. This is the single most important Supabase setting, and Reeve checks it by counting rows, never by reading them.
A leaked service_role key
Supabase gives you two keys. The "anon" key is public by design and safe in the browser. The "service_role" key bypasses all your security rules and must live only on a server. If it ever ends up in your app's front-end code, someone can do anything to your data. Reeve decodes the keys it finds and tells you exactly which one is exposed — safe "anon" gets a green check, "service_role" is a red alert.
Public storage buckets
Files people upload live in Supabase Storage "buckets." A bucket set to public means anyone can list and download what's inside — so private uploads can become visible to everyone. Reeve checks whether your buckets are listable; it never downloads anyone's files.
Your API open to any website (CORS)
Supabase gives your database a web address (via PostgREST). Combined with an over-permissive sharing setting, another website could call your data from a visitor's browser. Reeve checks whether your endpoints answer to strangers and to other sites — without ever using them to change anything.
Tables and endpoints exposed without rules
Every table you create is reachable through Supabase's API — that's by design, and RLS is meant to guard it. But a new table added in a hurry, before its rules are set, can be briefly (or lastingly) open. Reeve checks what's actually reachable from the outside.
Keys or config left in the deployed app
Beyond Supabase's own keys, apps often carry other settings and secrets in their front-end code or an exposed .env. Reeve reads your app's loaded code and checks for reachable config files, then tells you which values are safe to be public and which aren't.
What Reeve is — and isn't
Reeve is a free, read-only check from the outside — like an inspector trying the doors without stepping inside. It's fast and catches the common, high-impact mistakes. It is not a full security audit, and a clean grade isn't a guarantee — it means the obvious doors are shut. Everything Reeve does is passive: it counts rows rather than reading them, and never downloads your files.
Supabase gives you real security tools — a Security Advisor and database linter that flag RLS and exposure problems right in the dashboard — and they're genuinely worth using. What Reeve adds: most people building on Supabase live in their app builder, not the SQL editor, and the advisor speaks developer. Reeve checks your whole app from the outside — the way an attacker would reach your data — and explains what it finds in plain words. And if you'd rather not watch it yourself, we can.
Want it handled, not just checked?
Reeve Care keeps watching your app, backs up your data, and helps you fix things when they break — so you can keep building instead of worrying.
Learn about Reeve CareQuestions, answered honestly
What is Supabase RLS and do I really need it?
RLS (Row Level Security) decides who can see or change each row in your tables. Because your app ships a public "anon" key that can query the database directly, RLS is what keeps one user's data from being visible to everyone. Yes — for any table with real data, you need it on. Reeve checks whether it is, without reading your data.
Is the Supabase anon key safe to expose?
Yes — the "anon" key is designed to live in your front-end, and on its own it only does what your RLS rules allow. The key that must never be exposed is the "service_role" key, which ignores all rules. Reeve decodes the keys in your app and tells you which is which.
What happens if my service_role key leaks?
The service_role key bypasses every security rule, so anyone who has it can read, change or delete all your data. If it's in your front-end code, treat it as compromised: rotate it in the Supabase dashboard and move it to a server. Reeve flags an exposed service_role key as a critical issue.
Can Reeve check my Supabase without my database password?
Yes. Reeve only uses what your app already exposes publicly — the same anon key and endpoints any visitor's browser uses. It never needs your database password, never logs in as an admin, and never reads or downloads your rows or files.
Built your app in a specific tool? Here's the same honest rundown for:
Automated external check, not a full audit. Absence of findings is not a guarantee of safety.