Back to Blog

The Supabase RLS Security Checklist for 2026

In this article

• Quick Answer
• Key Takeaways
• What Is Row Level Security and Why Does It Decide Everything
• What Happened in the CVE-2025-48757 Lovable Exposure
• Why Do New Tables Sometimes Ship Without RLS
• The Supabase RLS Security Checklist
• Let Supabase Audit Itself First
• How We Approach a Supabase Security Audit
• Frequently Asked Questions

Supabase gives your app a Postgres database that the browser can talk to directly. That is what makes it fast to build on, and it is also what makes row level security the one setting you cannot get wrong. When a client reads the database with the public key, the only thing standing between a stranger and your data is your RLS policies. This checklist walks through every check we run on a Supabase project before it ships, with the exact SQL and requests you can run yourself today.

What Is Row Level Security and Why Does It Decide Everything

Row level security is a Postgres feature that attaches rules to a table so each database role only sees the rows a policy allows. Supabase leans on it for a specific reason. Your frontend holds a public key, the anon key, and uses it to query the database straight from the browser through the auto generated REST and GraphQL API. There is no backend in the middle deciding who sees what. The database itself makes that call, and it makes it using your RLS policies.

This is the trade. You get a database the client can query without writing an API layer, and in exchange the correctness of your access rules becomes the entire security model. Supabase says this plainly in the dashboard, where a table without RLS carries a warning that data access from the browser is safe only as long as you enable row level security.

When RLS is missing, the anon key is not a locked door. It is a working credential that can read, and often write, any table that lacks a policy. Anyone can find it, because it ships to every visitor in your JavaScript.

What Happened in the CVE-2025-48757 Lovable Exposure

The clearest illustration of the risk is a documented one. In 2025 the security researcher Matt Palmer disclosed CVE-2025-48757, an exposure affecting apps generated by the AI builder Lovable. He notified the vendor in March 2025 and published on 29 May 2025 after the disclosure window passed.

The numbers are worth stating exactly because they are often repeated wrongly. Palmer scanned 1,645 projects from Lovable public showcase and found 170 of them, roughly 10.3 percent, with inadequate row level security, exposing 303 endpoints in total. What leaked through those endpoints included names, emails, phone numbers, home addresses, payment information, and third party API keys. The scores assigned to the CVE do not fully agree, and you should know both. The national vulnerability database lists it as 9.3, critical, while Palmer own advisory scored it 8.26. Lovable has disputed the CVE, and its position is that customers own the security of their app data.

The mechanism matters more than the label. Lovable generated apps that queried the database directly from the client with the public key and relied on RLS alone to protect the data. When the generated tables had no policy, the public key could pull entire tables. This is not a Lovable specific flaw so much as the natural failure mode of any Supabase app where a table reaches the client without a policy. If your app was built fast, by an AI tool or otherwise, it is exactly the situation this checklist is designed to catch. It is the same class of mistake as the 2025 Tea app breach, though that incident involved a misconfigured Firebase storage bucket rather than Supabase, a reminder that direct client access to a data store is unforgiving when the rules are missing.

Why Do New Tables Sometimes Ship Without RLS

Here is the single most important technical detail on this page. Supabase enables row level security automatically only when you create a table through the Table Editor in the dashboard. Create the same table with raw SQL, through the SQL editor, in a migration file, or with an ORM like Prisma, and RLS is off until you turn it on yourself. The Supabase docs say exactly this, reminding you to enable RLS yourself when you create a table in SQL.

That is why AI built and migration driven apps are the ones that leak. The tools that scaffold a schema for you almost always create tables in SQL, which is the path that does not protect them by default. A developer clicking through the Table Editor is quietly protected. A code generator writing migrations is not, and nothing stops the app from shipping.

The Supabase RLS Security Checklist

Work these in order. The first three are the ones that catch real exposures. The rest close the gaps around them.

How Do You Find Every Table Missing RLS

Run this in the SQL editor to list every table in the public schema and whether row level security is on.

select schemaname, tablename, rowsecurity
from pg_tables
where schemaname = 'public'
order by rowsecurity asc, tablename;

Any row where rowsecurity is false is reachable through the API with the anon key. Enable it on each one, then confirm a policy exists, because a table with RLS enabled and no policy denies all access and will break your app in the opposite direction.

alter table public.your_table enable row level security;

How Do You Prove a Table Is Actually Protected

Do not trust the dashboard alone. Test the live API the way an attacker would, with nothing but your public anon key and the project URL.

curl "https://YOUR_PROJECT_REF.supabase.co/rest/v1/your_table?select=*" \
  -H "apikey: YOUR_ANON_KEY"

A protected table returns an empty array or an error. If you get back real rows from a table that should be private, that table is exposed to the public internet right now. This is precisely the method used to find the CVE-2025-48757 projects, and it takes seconds.

Is Your Secret Key Anywhere Near the Client

The secret key, historically called the service_role key, uses the Postgres BYPASSRLS attribute. It skips every policy you have written, by design, so it exists only for trusted server code such as backends and edge functions. One copy in a client bundle makes your entire RLS layer irrelevant. Search your built JavaScript, mobile bundles, and git history for it.

git grep -i "service_role" $(git rev-list --all) 2>/dev/null

The only Supabase key that belongs in client code is the publishable anon key. Supabase now returns a 401 when a secret key is used from a browser, but you should never rely on that as your control.

Are Your Policies Written Correctly

A table can have RLS on and a policy present and still be wrong. The two common mistakes are a policy that matches every row and a write policy that never checks what is being written. A policy using true as its condition allows everything. A policy with only a USING clause filters reads but leaves inserts and updates unconstrained, so add a WITH CHECK clause for writes.

create policy "Users read their own rows"
on public.profiles for select
using ((select auth.uid()) = user_id);

create policy "Users write their own rows"
on public.profiles for insert
with check ((select auth.uid()) = user_id);

Wrapping auth.uid() in a select lets Postgres cache it per statement, which keeps policies fast as tables grow. Make sure the unauthenticated case behaves the way you expect, since auth.uid() is null when there is no logged in user.

Do Your Views and Functions Bypass RLS

Postgres views run with the permissions of their creator by default, which means a view can return rows the underlying table policy would have blocked. On Postgres 15 and later, set views to run as the caller instead.

alter view public.your_view set (security_invoker = true);

The same care applies to functions marked security definer, which run with elevated rights. Confirm that none of them are callable by the anon role unless you intend it, and pin the search_path on every function to avoid injection through a mutable path.

Is Your Storage Locked Down

Supabase Storage is governed by policies on the storage.objects table, the same RLS model as your database. Buckets are private by default, and a private bucket enforces policies on every operation including downloads. A public bucket serves any file to anyone who has the URL, so mark a bucket public only when the files in it are genuinely meant for the open web.

Are Your Edge Functions and Auth Hardened

Edge functions verify the caller JWT by default and return a 401 without a valid token. Only make a function public deliberately. Then finish with the account and auth settings that Supabase lists in its own production checklist. Turn on SSL enforcement, add network restrictions on the database, protect your Supabase account with multi factor authentication, enable email confirmations, and set the one time password expiry to an hour or less.

Let Supabase Audit Itself First

Before you run any of the above by hand, open the Security Advisor in your project dashboard. It is a database linter that Supabase runs for you, and it flags the exact problems this checklist targets, including row level security disabled on public tables, RLS enabled with no policy, security definer views, functions with a mutable search path, and sensitive columns exposed through the API. It is the fastest way to find the obvious holes, and it is free. Treat it as the first pass and this checklist as the thorough one.

How We Approach a Supabase Security Audit

We productionize apps built fast, including ones generated by AI tools, and a security pass is always the first thing we run. The pattern is the one above. Enumerate every table and its RLS state, prove exposure with live requests rather than trusting settings, pull the secret key out of anywhere a client can reach, then work through storage, views, functions, and auth. Because we deliver under an ISO/IEC 27001:2022 certified information security management system, that audit is documented rather than ad hoc. If you have shipped a Supabase or Lovable app and you are not sure whether your data is protected, our MVP build and rescue service includes a free architecture and security audit, and our Lovable development and rescue work covers this exact class of exposure.

Frequently Asked Questions