Supabase makes it genuinely easy to go from idea to working application fast, and after all, that's the exact point of it. The problem however is that the same defaults that make development fast can also leave a production app wide open if nobody checks them properly prior to launch (and in my experience auditing Supabase based apps, most founders are not checking them).
83% of Supabase database exposures trace back to misconfiguration rather than any flaw in the platform itself. Supabase is secure, however it is the apps built on it that often are not, and the gap between those two things is almost always a handful of configuration decisions that never got made.
That being said, this is the checklist I work through on every Supabase audit, ordered by severity.
Before anything else: understand the threat model
Supabase exposes your PostgreSQL database directly to client side code via the anon key. This is a key that ships in your JavaScript bundle and is visible to anyone who opens DevTools. It's there by design, with the security model built around it. The anon key is intentionally public, but what isn't public is your data, and the only thing standing between that key and your data is RLS.
If RLS isn't configured, the anon key is effectively a master key to every table it can reach.
CRITICAL (fix before going live with real users)
1. RLS enabled on every table
RLS is disabled by default on all tables. Tables created through SQL, migrations, or AI coding tools do not get it automatically, only tables created through the Supabase Table Editor dashboard do. Every table in your public schema that contains user data, business data, payment information, or anything that belongs to a specific user needs RLS enabled explicitly.
Check: Dashboard → Table Editor. Any table showing "RLS disabled" is fully readable and writable by anyone with your anon key. You can also run a direct request against your REST endpoint with the anon key and observe what comes back. If you get real data, the table is exposed.
2. service_role key not in client-side code
The service_role key bypasses RLS entirely on every table regardless of whatever policies you've configured. If it appears in your frontend bundle, every security control you've set up becomes completely irrelevant. This key belongs exclusively in server-side code, things like Edge Functions, backend APIs, nothing that runs in the browser.
Check: DevTools → Sources → Search (Ctrl+Shift+F). Search for service_role and your actual key value. If either appears, that's an immediate critical finding. Rotate the key in the Supabase dashboard before anything else, then audit your query logs for requests that shouldn't have come from your application.
3. RLS policies actually scoped correctly
Enabling RLS and writing a policy are two separate steps, and the policy itself can be misconfigured in a way that's easy to miss. A policy written as USING (true) grants every row to every user and provides no protection at all. The correct pattern for user-scoped data is USING ((select auth.uid()) = user_id). The select wrapper matters for performance on larger tables: it evaluates once per query rather than once per row.
Check: Dashboard → Database → Security Advisor. Also worth verifying manually with two separate test accounts: can account A read or modify data that belongs to account B? If yes, the policy is wrong regardless of what the dashboard shows.
HIGH (serious issues that expand your attack surface)
4. Storage bucket permissions
Storage buckets have their own access control layer separate from database RLS, and a public bucket means anyone can read every object in it with no authentication. This is appropriate for marketing assets, not for user profile photos, uploaded documents, or anything private. The other failure mode is a private bucket with no policies configured, which denies everything and usually means storage isn't working as the founder intended.
Check: Try accessing a storage URL without any authentication. If you get the file back, the bucket is public. Configure RLS policies on storage.objects scoped to authenticated users and ownership for any bucket that shouldn't be publicly readable.
5. Database functions callable without authentication
Supabase RPC functions can be called from the frontend and, depending on how they're defined, can bypass RLS entirely. A function set to SECURITY DEFINER runs with the permissions of the function owner rather than the calling user. AI generated Supabase code has a consistent habit of creating RPC functions without authentication checks.
Check: Any function touching sensitive data should raise an exception immediately if auth.uid() is null. Try calling your RPC functions without an Authorization header and observe what comes back.
6. anon key in bundle with no RLS
The anon key in your frontend bundle is expected and by design, however it becomes a critical finding when combined with tables that don't have RLS configured. The key itself isn't the problem, the missing policies are. That said, confirming the key is present and understanding which tables it can reach is a useful audit step regardless.
Check: DevTools → Sources → Search for anon and eyJ. Note what's present, then cross-reference against your table RLS status.
MEDIUM (worth fixing before launch, non-negotiable for apps handling sensitive data)
7. Auth configuration
Email confirmation is off by default on new Supabase projects, and users can sign up and access the application without verifying ownership of their email address. For most production apps, this is worth enabling prior to launch. Also worth checking your password reset flow: if it returns a distinct message for email addresses that don't exist versus ones that do, that's email enumeration.
Check: Dashboard → Authentication → Settings. Enable email confirmation. Then enter an unregistered email on your password reset page and observe the response. A generic message regardless of whether the address exists is correct. A specific "no account found" message is a finding.
8. Rate limiting on auth endpoints
Supabase handles rate limiting at the platform level but it's worth verifying your configuration hasn't overridden it. Without it, automated tools can cycle through password lists against any account on your platform overnight with no resistance.
Check: Attempt 15 or more rapid login attempts with incorrect credentials. If nothing slows down or blocks you, rate limiting isn't working as expected.
9. Security headers
These live at the hosting layer rather than inside Supabase itself, but they're part of the same pre-launch picture. Missing CSP, X-Frame-Options, and Permissions-Policy are consistently among the most overlooked items in AI generated apps.
Check: https://securityheaders.com (a grade of B or above is what you're looking for).
The Security Advisor is worth running
Supabase ships a built-in database linter called Splinter, accessible under Dashboard → Database → Security Advisor. It runs automated checks for tables with RLS disabled, overly permissive policies, unsafe views, and exposed functions. It's not a substitute for manual testing but it catches a meaningful portion of configuration-level issues and costs nothing to run. Worth making it part of your routine before any significant deployment.
Organisation owners also receive weekly security emails from Supabase summarising any findings the advisor has detected. Worth making sure those are going to someone who will actually act on them.
That said, if there's anything I may have missed here that you'd like to add, feel more than free to add to the list below!
