Supabase gives you a database and an API in minutes, and that is exactly the danger: the API is exposed from the first moment. If you do not configure security, anyone with your public key can read and write your tables. Here is what to review.
RLS enabled on EVERY table
Row Level Security is Supabase's main barrier. Without it, the anon key can query whole tables straight from the browser. The classic vibe coder mistake is spinning up a new table fast and forgetting to enable RLS.
Check table by table in the dashboard: if any shows up without RLS, it is open to the public. Enabling it is not enough either: a table with RLS on but no policies denies everything, and one with an overly permissive policy protects nothing.
service_role versus anon
The anon key is public and goes in the frontend: it is meant to be governed by RLS. The service_role key bypasses RLS entirely and has full access. It must never appear in the browser or in a NEXT_PUBLIC_ variable.
Use it only on the server, in edge functions or trusted backends. If you suspect it has leaked, rotate it immediately from the dashboard.
Policies that truly reflect who can do what
A policy of true for everyone leaves the table open even with RLS on. Write specific policies: let a user read and edit only their own rows, usually by comparing auth.uid() with the owner column. Split rules by operation (select, insert, update, delete): sometimes you want to allow reads but not deletes.
Storage: buckets have rules too
File storage uses its own policies. A public bucket serves any file by URL to anyone who has it. Decide which buckets are public on purpose and protect the rest with user-based policies. Upload private documents to private buckets, not to a public one with hard-to-guess names.
Secrets and keys out of the frontend
Beyond the service_role, check there are no third-party keys (Stripe, email, AI) baked into client JavaScript. AI sometimes drops them there to make something work fast, and they stay visible forever.
Scanaris reviews your Supabase for you
Scanaris includes an optional Supabase audit that checks whether your tables have RLS and detects keys exposed in the frontend. It is a read-only check over what is already public, and every finding comes with a prompt ready to paste into your AI. Run it before launch and you will know if you left a door open.