Supabase Security Audit

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

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.

The 3 diagnostic SQL queries

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

Query 1 — Tables with 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 — Tables with 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 — 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 an LRC Supabase audit finds, in numbers

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';

Frequently asked questions

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.

What is the service_role key risk?

The service_role key bypasses all RLS 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.

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 complete automated check, use the free scanner 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, delivered in under 2 minutes. 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.

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.