AI & TechnologySupabase Security Review Before Launch (2026)

A Supabase security review before launch answers one question: can a stranger, or a signed-in user, read or change data they shouldn't? Start with the Security Advisor and fix its ERROR-level findings. Then work through the ten checks below, from secret keys and Row Level Security to storage, Edge Functions, email and backups. The checks come from Supabase's own documentation, read on October 21, 2026. The fix order is my own judgement. It applies whether you wrote the app yourself or built it with Lovable, Bolt or v0. I sell a review like this, and I say where that applies.

Step 0: run the Security Advisor

Supabase ships the Security Advisor: deterministic checks on your database. You can run it from the Security Advisor page in the dashboard, with supabase db advisors in the CLI, or through the MCP server or Management API. Supabase notes that some findings may be intentional, so read each one rather than silencing it.

The findings Supabase rates ERROR are the place to start. They include:

A clean Advisor run is a start, not the finish. It can't tell whether your policies match what your app should allow.

The 10 checks

1. No secret key in the browser

Supabase has two kinds of key. Publishable keys (sb_publishable_..., and the legacy anon key) are meant for the browser. Secret keys (sb_secret_..., and the legacy service_role key) bypass Row Level Security and must stay on the server. Supabase blocks secret keys used from a browser with a 401, but a secret or service_role key that ships in your front-end code is still exposed and should be treated as leaked.

Check: search your front-end code and built JavaScript for service_role and sb_secret_. Supabase's docs say the legacy keys are deprecated by the end of 2026, so plan to move to the new keys.

2. Row Level Security on every exposed table, with real policies

The publishable key only stays safe if Row Level Security (RLS) protects every table in an exposed schema. With RLS enabled and no policies, nothing is readable through the API with a publishable key. That is safe, but the app shows empty screens. The risky case is a policy that allows more than you meant, such as using (true) on a table of user data.

Check: sign in as a second test user and try to read, change and delete the first user's rows, directly through the API, not only through your screens.

Before a migration reaches the project, the free Supabase RLS policy checker reads the SQL in your browser and flags policies of true, sign-in-only checks and user_metadata roles.

3. Policies that trust user_metadata

Supabase warns that a policy relying on the user_metadata claim can create security issues, because signed-in users can modify it. A role or plan stored there can be set by the user. Keep roles in a table users can't write to, and check any policy the Advisor flags with rls_references_user_metadata.

4. Views and functions that skip your rules

Views bypass RLS by default, because they are usually created by the postgres user. On Postgres 15 and later, create them with security_invoker = true. A security definer function in an exposed schema can be called over the Data API with its creator's privileges, and Supabase says never to create one there.

5. New tables after October 30, 2026

Supabase is changing how new tables reach the API. It announced the change on April 28, 2026, made it the default for new projects on May 30, 2026, and enforces it on all projects from October 30, 2026. From then on, a new table in public isn't exposed until you grant access to anon, authenticated and service_role. Without the grant, the app gets error 42501, "permission denied for table". Tables you already have keep their grants. Supabase's recommended order is to grant, enable RLS, then add policies.

My October 30 permission denied guide has the SQL, and the free Supabase October 30 grants checker checks a migration in your browser.

6. Storage buckets

A public bucket skips access control when files are read, so anyone with the URL can open them. Uploads and deletes still need policies on storage.objects. The Advisor also flags public buckets with broad read policies that let anyone list every file.

Check: confirm that ID documents, invoices and private uploads sit in private buckets, with policies scoped to the owner.

7. Edge Functions

Edge Functions verify the caller's JWT by default (verify_jwt = true). Supabase advises leaving it on for user-facing functions. Turning it off to make a 401 go away removes the platform's check. After that, the function has to authenticate callers itself.

Check: list every function with verify_jwt = false and confirm each one checks its caller in code.

8. Auth email and redirects

Supabase's built-in email provider sends 2 emails per hour, only to pre-authorized addresses, with no delivery guarantee. Supabase urges setting up custom SMTP for real use. Without it, sign-up confirmations and password resets won't reach real users. For redirects, Supabase recommends setting the exact redirect URL path for your production site, and the redirectTo in your code must match the Redirect URLs list. Custom SMTP starts with a limit of 30 messages per hour, which you can raise, so check it against your expected sign-ups.

9. Passwords and MFA

Leaked password protection is available on the Pro plan and above. Supabase also advises against passwords shorter than 8 characters. Basic multi-factor authentication is available on all plans, and phone-based MFA is not on the Free plan and costs extra on Pro and Team.

10. Backups and network access

The Free plan has no automatic backups; you export with db dump yourself. Pro, from $25 a month, keeps daily backups for 7 days, and Team keeps them for 14 days. Point-in-time recovery is an add-on at $100 a month per 7 days of retention.

Network restrictions limit which IP addresses can connect to Postgres and its pooler. They don't cover the HTTPS APIs (PostgREST, Storage, Auth), so they don't replace RLS.

What to fix first

If you only have a day before launch, fix things in this order:

1. Any secret or service_role key in front-end code: treat it as leaked. Create a new secret key, put it in server-only settings, deploy, then disable the exposed key in Settings > API Keys (legacy keys stay active until you disable them). Removing it from the code alone does not help, because old builds and git history still contain it.
2. Tables without RLS, and policies that let one user read another's data.
3. Policies that read user_metadata.
4. Views and security definer functions in exposed schemas.
5. Private files in public storage buckets, and Edge Functions with verify_jwt = false that don't check their caller.
6. Grants on any table created after October 30, 2026, so the app doesn't break.
7. Custom SMTP, so sign-up and password-reset emails arrive.

Password and backup settings come next, before you take payments.

Built with Lovable, Bolt or v0?

AI builders create Supabase tables and policies for you, and it's easy to miss what they wrote. The same ten checks apply. The builder-specific details are in the Lovable, Bolt and v0 checklists.

Want it checked for you?

The App369 $450 Launch Check reviews your app from read-only access: your repository, a test login, and your migrations folder or a schema export with no user data. That covers the code and database checks above. Settings that exist only in the Supabase dashboard, such as your plan, email provider and backups, can't be seen from that access, so checks 8 to 10 are yours to do from this list. Within 3 business days you get each issue ranked critical, high or later, with where it is and how it was confirmed. You also get a fixed price to fix the worst of them. You can take that report to whoever you like, or fix it yourself. The AI-built app rescue page has the details. I'm one developer, based in Miami, and everything happens by email.