Supabase
A Supabase security checklist for apps going live.
Most Supabase exposure comes down to a short list: row-level security on every table, the service role key kept server-side, functions locked down, storage scoped, and auth configured. Work through these and you close the gaps that account for nearly every serious Supabase finding.
Secure once configured, open until then.
Supabase gives you everything you need to run a secure app, and almost none of it is on by default. Tables start open, keys are easy to misplace, functions can bypass your rules, and storage buckets can be more public than you think. None of it shows as an error while you build, so the checklist below is how you find the gaps before someone else does.
Row-level security
Enable RLS on every table that holds real data, with no exceptions for tables that seem harmless. For each table, write policies for select, insert, update and delete that match your actual rules. Confirm public-read tables still block writes, and confirm owner-scoped tables compare against auth.uid(). A table with RLS on but no policies is safe; a table with RLS off is fully exposed to the anon key.
Keys
The anon key is public and belongs in the front end. The service role key is secret and belongs only on the server; check it is not in your client bundle, client environment variables or git history. If the service role key was ever exposed, rotate it. Confirm no other third-party secrets ended up in client code alongside it.
Database functions
Any function callable with the anon key needs its own authorisation check, because functions that run as the definer bypass row-level security. Pay special attention to functions that create records, change roles, or mint tokens, licences or keys. A privileged function left open is as dangerous as an open table, sometimes more.
Storage and auth
Check each storage bucket's policies: which are public, which allow anonymous uploads, and whether private files are actually private. Anonymous upload access lets a stranger fill your bucket with files of their choosing. On auth, confirm email confirmation and password rules match your intent, and that role or plan changes cannot be triggered from the client without a server-side check.
Verify from the outside
Finally, stop trusting the configuration and test it. Query your tables with the anon key as a stranger would, run the two-account test to confirm users cannot reach each other's data, and probe your storage and functions. This outside-in verification is the difference between believing you are secure and knowing it, and it is exactly what our Supabase audit does.
Common questions.
- Is this checklist enough on its own?
- It closes the common, high-impact gaps, and working through it honestly puts you ahead of most Supabase apps. What a checklist cannot do is verify your specific policies are correct under real conditions; that needs testing each table and function from the outside, which is what an audit adds.
- Which item matters most?
- Row-level security. A missing or wrong policy behind the public anon key is the single most common serious Supabase finding, and it is the one that exposes user data directly.
- Can you run this for me?
- Yes. Our Supabase security audit works through every item on this list against your live project and hands you the fix for anything open.
Related services.
Let's build something real.
Tell us about your app or idea. You'll get a clear plan and a fixed quote back within 24 hours.