# Supabase Security Review Before Launch (2026)

> What to check in a Supabase project before launch: keys, Row Level Security, views, storage, Edge Functions, auth email and backups, with a fix-first order.

Canonical: https://app369.com/blog/supabase-security-review-before-launch-2026/
Last updated: 2026-10-31

[![Simon Dziak](https://app369.com/.netlify/images?w=48&amp;h=48&amp;fm=webp&amp;q=100&amp;url=%2Fimages%2Fszymon.jpg) **Simon Dziak** Founder & developer, App369](https://app369.com/about/szymon-dziak/) [LinkedIn](https://www.linkedin.com/in/szymondziak/)

Published October 21, 2026 · Updated October 31, 2026•Facts last verified October 24, 2026•6 min

App369https://app369.com/blog/supabase-security-review-before-launch-2026/

[← Back to Blog](https://app369.com/blog/)

**What to check in a Supabase project before launch: keys, Row Level Security, views, storage, Edge Functions, auth email and backups, with a fix-first order.**

**Disclosure:** App369 publishes this guide and sells a fixed-price Launch Check for AI-built apps, including Supabase apps.

## Key takeaways

- →Start with the Security Advisor in the Supabase dashboard (or `supabase db advisors` in the CLI). Its ERROR-level findings are the first things to fix.
- →Secret keys (sb_secret_ or the legacy service_role key) must never reach the browser. Publishable and anon keys are meant to.
- →Every table in an exposed schema needs Row Level Security with real policies, and policies must not trust user_metadata, which signed-in users can edit.
- →Views bypass RLS by default; set security_invoker = true on Postgres 15 and later. Security definer functions in an exposed schema can be called over the API.
- →From October 30, 2026, new tables need explicit grants, or the app gets "permission denied".
- →The built-in email provider sends 2 emails per hour, only to pre-authorized addresses, so set up custom SMTP before launch. The Free plan has no automatic backups.

Pricing an app? Try the free [app cost calculator](https://app369.com/tools/app-cost-calculator/) or get a range for your project in the [instant quote](https://app369.com/instant-quote/).

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:

| Lint | What it means |
| --- | --- |
| `rls_disabled_in_public` | A table in the public schema has Row Level Security turned off |
| `security_definer_view` | A view bypasses Row Level Security |
| `auth_users_exposed` | User data from `auth.users` is exposed through a view |
| `rls_references_user_metadata` | A policy trusts data that users can edit |

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. If a scanner flagged the key in your front end, [is the Supabase anon key safe in your frontend?](https://app369.com/fix/supabase-anon-key-exposed/) walks through the check.

**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](https://app369.com/tools/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, began rolling it out as the default for new projects on May 30, 2026 (over a few weeks), 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](https://app369.com/blog/supabase-permission-denied-new-tables-october-30-2026/) has the SQL, and the free [Supabase October 30 grants checker](https://app369.com/tools/supabase-oct-30-checker/) checks a migration in your browser. To test changes like these somewhere other than production, set up a [Supabase staging environment](https://app369.com/fix/supabase-staging-environment/) with Branching. If `supabase db push` later stops with a message about migration repair, the [db push fix](https://app369.com/fix/supabase-migration-failed-db-push/) shows how to find and close the gap.

### 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. If a bucket is already public, [check whether its files are exposed](https://app369.com/fix/supabase-storage-bucket-public/).

**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. If a browser call to a function fails with a CORS error, see the [Edge Function CORS fix](https://app369.com/fix/supabase-edge-function-cors-error/).

### 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. If confirmation emails link to localhost, see the [fix for auth emails that link to localhost](https://app369.com/fix/supabase-auth-email-links-localhost/). If sign-up fails with “email rate limit exceeded”, see the [email rate limit fix](https://app369.com/fix/supabase-email-rate-limit-exceeded/). If the emails arrive but land in spam, see the [fix for Supabase emails going to spam](https://app369.com/fix/supabase-auth-emails-going-to-spam/). Already seeing sign-in or email errors? The [Supabase Auth errors guide](https://app369.com/blog/supabase-auth-errors-sign-in-email-fixes-2026/) covers the 11 common ones.

### 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. The [exposed service_role key fix](https://app369.com/fix/supabase-service-role-key-exposed/) goes through Supabase’s rotation steps in order.
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. On the Free plan, a project that goes quiet for a week is paused: [restoring a paused Supabase project](https://app369.com/fix/supabase-project-paused/) covers getting it back and keeping it running.

## 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](https://app369.com/blog/lovable-app-rescue-2026/), [Bolt](https://app369.com/blog/bolt-app-rescue-2026/) and [v0](https://app369.com/blog/v0-app-rescue-2026/) checklists.

## Want it checked for you?

### **How much does it cost to fix a Supabase app?**

At App369, a $450 Launch Check finds and rates the problems in a Lovable, Bolt or Cursor app on Supabase. A $1,950 Rescue Sprint then fixes up to 5 of the critical or high ones if you want it (the $450 is credited). For ongoing fixes, the Monthly Dev Subscription starts at $1,495 a month.

- [**Check the whole app**$450Written report in 3 business days, each issue rated critical, high, medium or low](https://app369.com/fixed-price/ai-app-rescue/)
- [**Fix what the check finds**$1,950Rescue Sprint: up to 5 critical or high findings fixed in 7 business days. Quoted in your Launch Check report; the $450 is credited.](https://app369.com/fixed-price/ai-app-rescue/)
- [**Ongoing fixes and small features**from $1,495 a monthStarter: one app or website, one request at a time, about 2 business days each. Pause or cancel anytime.](https://app369.com/fixed-price/monthly-dev-subscription/)

[**See the Launch Check scope**](https://app369.com/fixed-price/ai-app-rescue/)

The [AI App Launch Check](https://app369.com/fixed-price/ai-app-rescue/) 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. Each issue comes with where it is and how it was confirmed. You can take that report to whoever you like, or fix it yourself. The [AI-built app rescue page](https://app369.com/fixed-price/ai-app-rescue/) has the details. If only your Row Level Security policies need work, the [Supabase RLS fix](https://app369.com/service/supabase-rls-fix/) covers that job on its own. I’m one developer, based in Miami, and everything happens by email.

## **Want this done at a fixed price?**

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

- [**AI-Built App Rescue**from $450A Lovable, Bolt or Cursor app checked end to end in 3 days, then its worst problems fixed at a fixed price.](https://app369.com/fixed-price/ai-app-rescue/)

## **Frequently asked questions**

<dl>

<dt>**What does a Supabase security review check?**</dt>
<dd>Which keys reach the browser, whether every exposed table has Row Level Security with correct policies, views and functions that skip those policies, storage bucket rules, Edge Function authentication, auth settings such as email delivery and redirect URLs, and backups.</dd>

<dt>**Is the Supabase anon key safe to put in my front end?**</dt>
<dd>Yes, the anon key and the newer publishable key are designed for the browser. They are only safe if Row Level Security protects your tables. The service_role key and the newer secret keys must stay on the server.</dd>

<dt>**How do I check my Supabase project for security problems?**</dt>
<dd>Open the Security Advisor in the dashboard, or run supabase db advisors in the CLI. Fix the ERROR-level findings first, then test your policies by signing in as a second user and trying to read the first user's rows.</dd>

<dt>**What happens if I turn off verify_jwt on a Supabase Edge Function?**</dt>
<dd>The platform stops checking the caller's JWT before your code runs, so a 401 goes away but anyone can call the function unless your code authenticates callers itself. Supabase advises leaving verify_jwt on for user-facing functions.</dd>

<dt>**Do I need a paid Supabase plan to launch?**</dt>
<dd>Not to launch, but check what you give up. The Free plan has no automatic daily backups and no leaked password protection; Pro starts at $25 a month with daily backups kept for 7 days.</dd>

</dl>

## **Sources**

1. [Supabase docs, Production checklist, fetched 2026-10-21](https://supabase.com/docs/guides/deployment/going-into-prod)
2. [Supabase docs, Advisors, fetched 2026-10-21](https://supabase.com/docs/guides/observability/advisors)
3. [Supabase docs, Database linter, fetched 2026-10-21](https://supabase.com/docs/guides/observability/advisors)
4. [Supabase docs, API keys, fetched 2026-10-21](https://supabase.com/docs/guides/getting-started/api-keys)
5. [Supabase docs, Row Level Security, fetched 2026-10-21](https://supabase.com/docs/guides/database/postgres/row-level-security)
6. [Supabase changelog, Tables not exposed to Data and GraphQL API automatically, published 2026-04-28](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically)
7. [Supabase docs, Storage access control, fetched 2026-10-21](https://supabase.com/docs/guides/storage/security/access-control)
8. [Supabase docs, Edge Functions auth, fetched 2026-10-21](https://supabase.com/docs/guides/functions/auth)
9. [Supabase docs, Auth SMTP, fetched 2026-10-21](https://supabase.com/docs/guides/auth/auth-smtp)
10. [Supabase docs, Redirect URLs, fetched 2026-10-21](https://supabase.com/docs/guides/auth/redirect-urls)
11. [Supabase docs, Password security, fetched 2026-10-21](https://supabase.com/docs/guides/auth/password-security)
12. [Supabase docs, Network restrictions, fetched 2026-10-21](https://supabase.com/docs/guides/platform/network-restrictions)
13. [Supabase docs, Database backups, fetched 2026-10-21](https://supabase.com/docs/guides/platform/backups)
14. [Supabase, pricing, fetched 2026-10-21](https://supabase.com/pricing)

Tags

#supabase security review #supabase security checklist #supabase row level security #supabase production checklist #supabase launch #vibe-coded app #ai app rescue

Generated from app369.com . © 2026 App369. All rights reserved.

**Share:**

[Share on Twitter](https://twitter.com/intent/tweet?text=Supabase%20Security%20Review%20Before%20Launch%20(2026)&amp;url=https%3A%2F%2Fapp369.com%2Fblog%2Fsupabase-security-review-before-launch-2026%2F) [Share on LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fapp369.com%2Fblog%2Fsupabase-security-review-before-launch-2026%2F) [Share on Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fapp369.com%2Fblog%2Fsupabase-security-review-before-launch-2026%2F)

## **Related Resources **

[Lovable vs Hiring a Developer: Finish Your Vibe-Coded App (2026)](https://app369.com/blog/hire-developer-finish-vibe-coded-app-2026/) [Cursor App Rescue: 7 Problems to Fix Before Launch](https://app369.com/blog/cursor-app-rescue-2026/) [Lovable App Rescue: 7 Problems to Fix Before Launch](https://app369.com/blog/lovable-app-rescue-2026/) [Bolt App Rescue: 8 Problems to Fix Before Launch](https://app369.com/blog/bolt-app-rescue-2026/) [v0 App Rescue: 8 Problems to Fix Before Launch](https://app369.com/blog/v0-app-rescue-2026/) [Supabase Database and Edge Function Errors: 12 Fixes (2026)](https://app369.com/blog/supabase-database-edge-function-errors-fixes-2026/)

## **Related guides **

[<h3>**Supabase "Permission Denied" on New Tables: the October 30 Fix**</h3>Supabase permission denied for table (42501): from October 30, 2026, new tables need explicit grants. What changes, who is affected, and the exact SQL fix.**Read more **](https://app369.com/blog/supabase-permission-denied-new-tables-october-30-2026/) [<h3>**Lovable App Rescue: 7 Problems to Fix Before Launch**</h3>Your Lovable app works in the preview, but real users are coming. The 7 problems to check first, from open tables to the Supabase October 30 change.** Read more **](https://app369.com/blog/lovable-app-rescue-2026/) [<h3>**Bolt App Rescue: 8 Problems to Fix Before Launch**</h3>Your Bolt app works in the preview, but real users are coming. The 8 problems to check first, from open tables and broken sign-up links to hosting limits.** Read more **](https://app369.com/blog/bolt-app-rescue-2026/) [<h3>**Firebase Security Rules Best Practices: The Complete Guide (2026)**</h3>Firebase security rules best practices for 2026 in one table: deny-all baseline, update checks, custom claims, validation, emulator tests and Cloud Functions.** Read more **](https://app369.com/blog/firebase-security-guide-2026/)