Supabase RLS & Security Checker
Check your Supabase database for Row Level Security issues and data exposure risks. VAS tests if your tables are properly protected.
$ vas explain --topic rls
> What is Supabase Row Level Security?
Row Level Security (RLS) is PostgreSQL's built-in feature that controls which rows users can access in your database tables. When enabled, every query is filtered based on policies you define.
Without RLS: Anyone with your Supabase anon key (which is public in your frontend code) can read, insert, update, or delete any row in tables with public access.
With RLS: You define policies that restrict access based on the authenticated user, their role, or custom conditions.
The Problem
AI code generators like Bolt.new and Lovable often create Supabase integrations without enabling RLS, leaving your data exposed.
SELECT * FROM users;
SELECT * FROM orders;
SELECT * FROM payments;
$ vas scan --platform supabase
> Common Supabase Security Issues
RLS Not Enabled
Tables without RLS enabled allow anyone with the anon key to access all data. VAS detects tables with RLS disabled and tests for actual data exposure.
ALTER TABLE users
ENABLE ROW LEVEL SECURITY;
Missing RLS Policies
Even with RLS enabled, you need policies to allow legitimate access. Without policies, no one can access the table—including your app.
CREATE POLICY "Users read own"
ON users FOR SELECT
USING (auth.uid() = id);
Service Role Key Exposure
The service role key bypasses RLS entirely. If exposed in client code, attackers gain full database access regardless of RLS policies.
const supabase = createClient(
url, SERVICE_ROLE_KEY // Bypasses RLS
);
Overly Permissive Policies
Policies that use "true" as the condition or don't properly check user identity provide no real protection.
CREATE POLICY "Allow all"
ON users FOR ALL
USING (true); -- Everyone can access
> What VAS Checks for Supabase Apps
Our Supabase security scanner performs comprehensive checks on your database configuration.
> How VAS Tests Your Supabase Security
VAS doesn't just check configuration—it actually tests for data exposure.
Extracts Supabase credentials
VAS finds your Supabase URL and anon key from your deployed application's JavaScript bundles.
Enumerates public tables
Using the anon key, VAS queries Supabase to discover which tables exist in your database.
Tests each table for exposure
VAS attempts to SELECT, INSERT, UPDATE, and DELETE on each table to see what's actually accessible.
Reports exposed data
If data is accessible, VAS reports the table name, record count, and sample column names (not actual data).
Provides remediation guidance
VAS gives you the exact SQL commands needed to enable RLS and create secure policies.