Supabase Security Audit

By Jai Mittal, CTO · Launch Ready Code · August 16, 2026

The vulnerabilities described here align with the OWASP Top 10, the industry-standard list of the most critical web security risks, and MITRE CWE Top 25. Severity uses CVSS v3 scoring from NIST's National Vulnerability Database.

RLS policies, secret key exposure, Edge Function auth, and Storage bucket permissions — the four layers that fail most often.

What are the 4 Supabase security layers to audit?

A Supabase security audit focuses on the four configuration layers that account for the large majority of critical and high-severity findings. These are not platform vulnerabilities — they are deployment decisions that AI builders routinely leave in their default (insecure) state.

This gap is not unique to hand-built Supabase projects. AI builders scaffold a Supabase backend the same way, including Bolt.new and Lovable. Built with Lovable? See our guide to secure a Lovable app end to end. Lovable ships RLS off by default too.

What are the 3 diagnostic SQL queries to run first?

Run these in your Supabase SQL editor to diagnose RLS issues in under 5 minutes.

Query 1: Which tables have RLS disabled (publicly accessible)?

SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public'
ORDER BY rowsecurity, tablename;

-- rowsecurity = false means the table is publicly readable and writable
-- rowsecurity = true  means RLS is on — check policies next

Query 2: Which tables have RLS on but no policies (fully locked)?

SELECT t.tablename
FROM pg_tables t
LEFT JOIN pg_policies p
  ON p.tablename = t.tablename AND p.schemaname = t.schemaname
WHERE t.schemaname = 'public'
  AND t.rowsecurity = true
  AND p.policyname IS NULL;

-- These tables have RLS enabled but zero policies
-- Result: inaccessible to everyone including authenticated users
-- Fix: add appropriate SELECT / INSERT / UPDATE / DELETE policies

Query 3: Which tables have permissive USING(true) policies (everyone gets full access)?

SELECT tablename, policyname, cmd, qual
FROM pg_policies
WHERE schemaname = 'public'
  AND qual = 'true';

-- qual = 'true' means the policy allows ALL users to access ALL rows
-- This is functionally the same as having RLS disabled
-- Fix: replace USING (true) with USING (auth.uid() = user_id)

What does an LRC Supabase audit find? The numbers

Based on scans run through launchreadycode.com as of June 2026:

Based on scans run through launchreadycode.com as of June 2026:

• RLS disabled or using USING(true) policies: majority of first-time scans
• service_role key in client bundle or Git history: present in a significant share of scans
• Edge Functions without JWT verification: common in AI-generated function scaffolding
• Public storage buckets with user-uploaded private files: found in apps with file upload features
• No error tracking or monitoring configured: majority of apps on first scan

How to fix Supabase RLS?

-- Step 1: Enable RLS on every table
ALTER TABLE users ENABLE ROW LEVEL SECURITY;
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

-- Step 2: Create owner-scoped SELECT policy
CREATE POLICY "users_select_own"
  ON users FOR SELECT
  USING (auth.uid() = id);

-- Step 3: Create owner-scoped UPDATE policy
CREATE POLICY "users_update_own"
  ON users FOR UPDATE
  USING (auth.uid() = id)
  WITH CHECK (auth.uid() = id);

-- Step 4: Verify no permissive policies remain
SELECT tablename, policyname, qual
FROM pg_policies
WHERE schemaname = 'public' AND qual = 'true';

What related Supabase security guides should you read?

• Free Supabase RLS & security checker — run a live check against your project URL.
• Supabase auth security checklist — the full pre-launch checklist beyond RLS.
• How to find exposed secrets in AI-generated bundles — for service_role keys and other secrets shipped to the client.
• Is Supabase safe? — what Supabase secures by default vs. what you must configure.

Frequently asked questions about Supabase security audits?

Is Supabase secure?

Supabase is a well-engineered platform with strong security primitives. The vulnerabilities found in Supabase-based apps come from configuration defaults — RLS is disabled by default on every table, a design choice documented in Supabase's own docs. AI builders scaffold schemas without enabling RLS, creating apps where the database is publicly accessible. All of these gaps are standard infrastructure hardening steps, fixable once identified. For what Supabase secures by default vs. what you must set up, see our is Supabase safe? guide.

What is the service_role key risk?

The service_role key bypasses all row-level security policies by design — it is meant for server-side administrative operations only. If it ends up in a client-side JavaScript bundle (common in AI-generated code that uses a single Supabase initialisation file for both client and server), any visitor to your app can extract it from their browser's DevTools and use it to read, modify, or delete your entire database. Rotate the key immediately and store it exclusively in server-side environment variables that are never shipped to the browser. For which Supabase key is safe to expose, see our anon key vs service_role key guide.

How do I check Supabase RLS?

Run this SQL in your Supabase SQL editor: SELECT schemaname, tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public' ORDER BY rowsecurity, tablename; Any row with rowsecurity = false is publicly accessible. Then check for permissive policies: SELECT tablename, policyname, qual FROM pg_policies WHERE schemaname = 'public' AND qual = 'true'; Policies with qual = 'true' allow all users access to all rows. For a full automated Supabase security checker — keys, Edge Functions, and Storage — run the free scan at launchreadycode.com.

What is CVE-2025-48757?

CVE-2025-48757 is a class of misconfiguration documented in May 2025 affecting 170+ production apps built with AI tools using Supabase. The root cause: RLS is disabled by default in Supabase; AI builders scaffold schemas without enabling it; the public anon key (embedded in the client bundle by design) could then be used to query any table and return all rows with no authentication required. The fix is enabling RLS on every table and replacing any USING (true) policies with owner-scoped USING (auth.uid() = user_id) policies.

How much does a Supabase security audit cost?

A free Launch Readiness Score is available at launchreadycode.com — URL-based, no signup, 60 seconds. The full Launch Readiness Audit Report covering all findings with severity, file references, and specific fixes is $499 one-time, engineer-verified and delivered within 48 hours. Ongoing daily monitoring starts at $149/month. The Code Care DFY Technical Setup ($1,999 setup fee + $2,999/mo) implements every fix — RLS policies, secret management, Edge Function auth, monitoring setup — with a senior engineer reviewing and applying every change. See our full Supabase auth security checklist for what to fix first.

Sources: CVE-2025-48757 (NVD / Matt Palmer, May 2025); byteiota.com/supabase-security-flaw-170-apps-exposed-by-missing-rls; OWASP Top 10 2021; CWE Top 25 2024; Supabase documentation. This page provides general security guidance, not a certification or guarantee.