Supabase Security Advisor: what it flags and what it misses

01What Supabase Security Advisor is

Supabase ships three Advisors: Health, Security and Performance. They are deterministic SQL (and, for Health, log) checks. They do not browse your app, do not sign in, and do not send requests as a user. The Advisor docs (checked 25 Oct 2026) list where you can run them:

• Studio: Database → Security Advisor (also Health and Performance).
• CLI: supabase db advisors. CLI PR 7297 (23 Oct 2026) adds --remote via the advisors API, so you can lint the hosted project from a terminal.
• MCP: get_advisors with type set to security or performance.
• Management API: the same checks, for agents and CI.

The security lints live in the open-source supabase/splinter repo. Each file is a view that returns rows when a pattern matches. A clean Advisor means those views returned no rows. It does not mean user A cannot read user B’s invoices.

Some findings are intentional. A public blog table should have SELECT … USING (true). A contact-form function should be SECURITY DEFINER so anon can insert one row. The docs say to check each finding against the access model you meant before you change anything.

02The security lints that matter, in plain words

These are the security lints a Lovable, Bolt.new or hand-written Supabase app actually trips. Summaries are from the Advisor docs (checked 25 Oct 2026). Fix SQL is the docs’ own remediation, shortened.

Related, and easy to mix up: lint 0008 (RLS on, no policy) is the “table is locked shut” warning. That is not a leak. It is the state you want until the owner policies exist. Lint 0011 flags a function whose search_path is mutable; pin it with set search_path = ''.

A green Advisor plus lint 0013 clean means every exposed table has RLS on. It does not mean the policies on those tables keep users apart.

03Why a table anyone can read raises no 0024 warning

This is the claim to verify yourself, because the docs and the lint SQL do not say the same thing.

The Advisor docs page for 0024_permissive_rls_policy describes USING (true) as a problem on SELECT: “Any user with the specified role can read ALL rows.” It lists USING (true), USING (1=1) and a missing USING on a permissive SELECT as detected patterns.

The lint that actually runs is lints/0024_rls_policy_always_true.sql in supabase/splinter (read 25 Oct 2026). The USING check is gated on command:

-- Note: SELECT with (true) is often intentional and documented,
-- so we only flag UPDATE/DELETE
command in ('UPDATE', 'DELETE', 'ALL')
and (
  normalized_qual in ('true', '(true)', '1=1', '(1=1)')
  or (qual is null and is_permissive)
)

The view’s own description field is explicit: “SELECT policies with USING (true) are intentionally excluded as this pattern is often used deliberately for public read access.”

So this table produces no 0024 row:

alter table public.notes enable row level security;

create policy "anyone can read notes" on public.notes
  for select to anon, authenticated
  using (true);

RLS is on. Advisor 0013 is silent. Advisor 0024 is silent. A signed-out GET /rest/v1/notes with only the public key returns every row. That is the “green dashboard, open table” case people keep hitting: the switch is on, a leftover USING (true) is still there, and the lint that sounds like it would catch it does not look at SELECT.

0024 does catch the write side: FOR UPDATE USING (true), FOR DELETE USING (true), an INSERT with an empty or true WITH CHECK, and FOR ALL. If your leak is a read, 0024 will not save you.

Two other policies the Advisor will also not call out, because they are not literally true:

• using (auth.uid() is not null) or using (auth.role() = 'authenticated') — every signed-in user sees every row. With open sign-up, that is anyone.
• using (auth.uid() = author_id) on a table whose owner column is user_id — the check sits on the wrong column, so it never matches the way you think, or it matches everyone if author_id is null.

Only a request that runs as a second user shows those. List the policies, then test:

select tablename, policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public'
order by tablename, cmd;

Anything whose qual is true, auth.uid() IS NOT NULL, or a check on user_metadata is a candidate. Then follow How to test Supabase RLS with two users.

04User impersonation and the RLS Tester preview

The Advisor is not Supabase’s only tool. Two others let you act as a user inside Studio. They are the right first check. They are not the same as hitting your deployed API.

User impersonation (public beta, supabase.com/features/user-impersonation, checked 25 Oct 2026) lets you pick a role or a specific user in the Table Editor, SQL Editor and GraphiQL. The grid and the query then obey that user’s RLS. Use it when you want to see, on real rows, what one account gets back. It runs inside the dashboard, as the role you chose, against the project you are already logged into as an owner.

RLS Tester is a feature preview (changelog, 28 Apr 2026; still listed as a preview in the June 2026 developer update). You turn it on from the profile menu. It lets you:

• Run a SQL query as signed out (anon) or as a signed-in user.
• See which RLS policies were evaluated for that query.
• Paste a client-library snippet; the Assistant infers SQL. The changelog says to verify that output.

The same changelog is honest about the limit: only SELECT. INSERT, UPDATE and DELETE are out of the preview because a mutation can fire triggers and Edge Functions. If your leak is a forged insert, a plan = 'pro' patch, or an RPC that writes, the Tester will not show it.

Use both. Then still hit /rest/v1/ with a real JWT from a test account. Impersonation answers “what does this role see in Studio?” The live API answers “what does the key in my shipped JavaScript actually return?” Those diverge when a grant, a security definer function, a storage policy or a view is in the path. The two-user tutorial has the curl.

05What a clean Advisor still cannot tell you

Say this the other way around, so it is not a knock. The Advisor is the right first pass. It is also the thing people treat as a finish line. Here is what a clean run still cannot answer:

• Can user A GET user B’s rows on a table whose SELECT policy is true, auth.uid() is not null, or the wrong column?
• Can user A POST a row with user_id set to B?
• Can user A PATCH their own role, plan or credits? RLS is per row, not per column.
• Can user A call /rest/v1/rpc/… with B’s id and get B’s data back? Lints 0028/0029 catch definer functions that are executable; they do not run the function as A.
• Does the deployed app expose a different key, a different schema, or a bucket the Studio lint did not see?

Lovable’s Quick scan covers some of the same configuration (RLS missing or always-true, leaked-password protection) and its Deep scan reads code for cross-user access. Neither signs in as two users against the live app. Aikido’s Lovable product does, at $100 per test launch pricing (checked 25 Oct 2026). You can also do it by hand: two throwaway accounts and the requests in the two-user guide. Preflight’s $29 Proof Report is one more way to run that same test and keep the requests. It is not the only way, and it writes a few marked canary rows on purpose.

06What Preflight checks that the Advisor does not

The free scan does not replace the Advisor. It looks at the published app from outside: the public key in the bundle, row counts signed out, auth settings, bucket list, headers and exposed files. GET and HEAD only, after you prove you own the domain.

The Proof Report signs in as two test accounts you create. It tries cross-user reads on tables, RPCs and storage, a forged-owner insert, and privilege-column changes which it sets back and reads again. It writes marked canary rows on purpose. Leftover canary rows get a one-line DELETE in the report. Other tools run a credentialed cross-user test too; the difference is price, that it works whatever built the app, and a dated report with curl you can re-run. See Compare (checked 25 Oct 2026) and the sample report.

Run the Advisor on every migration. Then run a two-user test on the live app before you share it. A clean lint plus a failed cross-user GET is a real finding, not a disagreement between tools.

?Questions people ask

• Is a clean Supabase Security Advisor enough?

  No. It means the lints that ran found nothing. Lint 0024 skips SELECT USING (true), and no lint can tell whether auth.uid() = user_id sits on the right column. Test as two users as well.

• Does Security Advisor flag SELECT USING (true)?

  No. The lint SQL in supabase/splinter only flags UPDATE, DELETE and ALL for an always-true USING, plus INSERT WITH CHECK. SELECT is excluded on purpose. Read the policy list yourself.

• Does the Advisor only check whether RLS is on?

  No. It also lints permissive UPDATE/DELETE/INSERT policies, SECURITY DEFINER views and functions, user_metadata in policies, public bucket listing, auth.users exposed through a view, and more. RLS-off is lint 0013, one of many.

• Can I test as a user inside Supabase?

  Yes. Impersonate a user in the Table Editor or SQL Editor, and turn on the RLS Tester preview for SELECT. For writes and for the deployed API, use curl with two JWTs or a tool that signs in as two accounts.

• Does Preflight replace the Advisor?

  No. Run both. The Advisor is free, in-dashboard, and catches configuration. Preflight’s free scan is outside-in; the $29 Proof Report is the two-user test on the live app. Aikido and others offer a two-user test as well.

• Where do I run supabase db advisors?

  In a project with the Supabase CLI. supabase db advisors lints the local database; --remote (CLI PR 7297, 23 Oct 2026) talks to the hosted project through the advisors API.

→Related guides

• Supabase RLS checkerTest row level security as no one, then as two users. SQL and curl included.
• Lovable security scanWhat Lovable’s Quick and Deep scans cover, and how to test the live app yourself.
• Supabase anon key exposed?Why the anon or publishable key is meant to be public, and what actually leaks.
• Supabase security checklist24 checks with SQL, grouped, each marked with whether Preflight tests it.
• Supabase service_role key leakedConfirm the leak, rotate without downtime, and check what was touched.
• Supabase storage: public vs private bucketsPublic vs private buckets, owner-folder policies, signed URLs and how to test them.
• Bolt.new security: before you publishWhat Bolt.new checks for you, what it can’t see, and how to test the live app.
• Vibe coding security checklist20 checks for apps built with AI tools, from data leaks to headers and email.
• Supabase 42501 “permission denied for table” (30 Oct change)From 30 Oct 2026 new Supabase tables need a GRANT. The safe fix, the quick fix that leaks, and how to check a Lovable app.
• How to test Supabase RLS with two usersCreate two users, insert as A, query as B with SQL, curl and JWTs. Then what Preflight automates.