Supabase Security Advisor warnings: which ones mean your data is open

What each Supabase Security Advisor warning means for a vibe-coded app, which to fix first, and the AI fixes that quietly reopen your data.

The Security Advisor runs fixed checks on your Supabase database and sorts what it finds into ERROR, WARN and INFO. Most ERROR-level security findings, like "Table publicly accessible", describe data your public API can reach right now, so fix those first. WARN depends on what the data is for. An empty list doesn't prove your app is safe: the advisor can't know which data should be private, and it doesn't look at your frontend.

The advisor never reads your live site. To check it for leaked keys, scan it free.

Where to find it

In the dashboard, open Advisors → Security Advisor. The same checks run from the CLI with supabase db advisors, from the Supabase MCP server's get_advisors tool, and from the Management API (Supabase docs). Supabase notes some findings may be intentional, so check each against what the data is for.

Why vibe-coded apps light it up

AI builders create tables, views and functions fast, often without anyone reading the SQL. Supabase gave that as the reason for its newest default: from October 30, 2026, new tables in the public schema on existing projects need an explicit grant before the API can see them. Existing tables keep their current grants, so a table that is open today stays open until you fix it (Supabase changelog).

Open tables are the failure behind CVE-2025-48757: the researchers reported 303 exposed endpoints across 170 of 1,645 Lovable projects they checked, including user and payment data (researchers' statement). They also argued that checking a policy exists isn't checking it's correct.

The warnings that matter most

Summaries, lint numbers and levels are Supabase's (Supabase docs).

Fix them in this order

1. Close open tables. For each "Table publicly accessible" finding, run alter table public.your_table enable row level security;. Then add owner-only policies (examples) or your app can't read it. If it holds tokens or API keys, assume they were read and rotate them.
2. Fix views that skip RLS. Recreate each flagged view with with (security_invoker = on) so the caller's policies apply. For views over auth.users, Supabase recommends a public.profiles table filled by a trigger.
3. Stop trusting user_metadata. Users can edit their own user_metadata, so a policy reading an is_admin flag from it lets anyone make themselves admin. Keep roles in a table users can't write, or in app_metadata, which only your server can set.
4. Replace always-true policies. using (true) is fine for a public product list and a leak on invoices. Use (select auth.uid()) = user_id on anything personal. Permissive policies combine with OR, so the loosest one wins.
5. Lock down security definer functions. These run with the owner's rights and skip RLS, and Postgres lets everyone execute a new function by default, and Supabase also grants it to anon and authenticated, so a function in public is callable at /rest/v1/rpc/name unless you revoke it. If a function isn't meant for visitors, run revoke execute on function public.fn(args) from anon, authenticated, public;, or switch it to security invoker.
6. Clear the lower-risk warnings. Add set search_path = '' to flagged functions and fully qualify names inside them. Move extensions out of public with alter extension name set schema extensions;. Turn on leaked password protection if your plan has it (Supabase password security).
7. Re-run it, then test from outside. Refresh the advisor until the ERRORs are gone. Then test your RLS signed out and as two users, because a clean advisor only means no rule matched.

Watch out for "fixes" that make it worse

AI tools tend to pick whatever makes an error disappear. Three common ones: adding using (true) to silence "No access rules defined", turning RLS back off because the app stopped loading data, and running grant ... on all tables in schema public to anon after a permission denied for table error. Each clears a message and reopens the data.

Checklist

• No ERROR-level security findings left in the Security Advisor.
• Every public table has RLS on and policies that check ownership.
• Any token or key that sat in an open table has been rotated.
• Public views use security_invoker = on; none expose auth.users.
• No policy reads user_metadata for roles.
• using (true) only on data meant to be public.
• Security definer functions are revoked from anon and authenticated unless they're meant to be public.
• Signed-out and two-user tests pass.
• No service_role or sb_secret_ key in your frontend.

Run the Supabase Security Advisor (supabase db advisors, or the MCP get_advisors tool with type security) and list every ERROR and WARN with the table, view or function it names. For each one, propose the fix and explain what it changes for anon and authenticated users. Do not use using (true), do not disable RLS, and do not grant on all tables to make a warning go away. Wait for my OK before running any SQL.

FAQ

Does an empty Security Advisor mean my app is secure?
No. It checks database settings one rule at a time. It can't know which data your app should keep private, and it doesn't read your frontend, where leaked keys live. Test your tables from outside and scan your live site too.

Do I need to fix "Function search path mutable"?
Yes, but it isn't urgent like an open table. Add set search_path = '' to the function and use full names such as public.profiles inside it. Test the function afterwards, because unqualified names will stop resolving.

Why can't I turn on leaked password protection?
Supabase offers it on the Pro plan and above. It rejects passwords found in the HaveIBeenPwned breach list. On the free plan, set a longer minimum password length in your Auth settings instead.

My AI tool cleared the warning with using (true). Is that fine?
Only for data that is meant to be public, like published blog posts. On anything personal, using (true) means every visitor can read every row. Ask for an owner check such as (select auth.uid()) = user_id.

What changed on October 30, 2026?
Supabase now applies explicit grants to existing projects: new tables in public aren't reachable through the Data API until you grant access. Existing tables keep their grants. Grant only what each role needs, and keep RLS on.

Related: How to test Supabase RLS · Enable Supabase RLS · Supabase Storage bucket security

Sources (all fetched 2026-10-30)

1. Supabase, Advisors (every lint, level and fix): https://supabase.com/docs/guides/database/database-advisors
2. Supabase changelog, tables not exposed automatically: https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically
3. Supabase, Securing your API (grants and default privileges): https://supabase.com/docs/guides/api/securing-your-api
4. Supabase, Password security: https://supabase.com/docs/guides/auth/password-security
5. NVD, CVE-2025-48757: https://nvd.nist.gov/vuln/detail/CVE-2025-48757
6. Statement on CVE-2025-48757: https://mattpalmer.io/posts/statement-on-CVE-2025-48757/

Want the whole pre-launch process in one place? Get App Security for Vibe Coders, our $9 PDF playbook. See what's inside.

More guides

• Is my Lovable app secure?
• How to enable Supabase Row Level Security (RLS)
• Exposed Supabase service_role key: what to do now
• Lovable security checklist