RLS Checker
Automatically test your Row Level Security policies. We query your database exactly like an attacker would to verify your data is protected.
What is Row Level Security?
Row Level Security (RLS) is a PostgreSQL feature that controls which rows users can access in a table. It's your database's last line of defense—without it, anyone with your API credentials can access all data.
Without RLS
SELECT * FROM users;
→ Returns ALL users
With RLS
SELECT * FROM users;
→ Returns only YOUR data
How We Test Your RLS
Unauthenticated Access
We attempt to query your tables without authentication to verify anonymous users can't read data.
Cross-User Access
Tests whether authenticated users can access other users' data by manipulating queries.
Table Discovery
Automatically discovers all tables in your database and checks each one for RLS policies.
Policy Verification
Reports which tables have RLS enabled but may have overly permissive policies.
Works With
Supabase
PostgreSQL + RLS
Neon
Serverless Postgres
PlanetScale
MySQL (similar concepts)
Any PostgreSQL
Self-hosted or cloud
What You'll Get
Frequently Asked Questions
Supabase RLS enabled but still can access all data - why?
RLS is enabled but you haven't created any policies yet. Without policies, RLS blocks EVERYTHING by default. You need to create SELECT/INSERT/UPDATE/DELETE policies that define who can access what. VAS shows exactly which tables are exposed and provides policy templates.
How to test if RLS is working correctly?
Option 1: Use VAS to automatically test your tables with the anon key. Option 2: Manually test in Supabase SQL Editor with 'set role anon' then query your tables. If you can read data you shouldn't, your policies are wrong.
RLS policy for users can only see their own data
CREATE POLICY "Users see own data" ON your_table FOR SELECT USING (auth.uid() = user_id). This ensures the authenticated user's ID matches the user_id column. Apply similar policies for INSERT, UPDATE, DELETE. VAS provides these templates for your specific tables.
Supabase anon key vs service role key - security difference?
Anon key: Public, subject to RLS policies, safe for frontend. Service role key: BYPASSES ALL RLS, full database access, NEVER expose in frontend. If service_role key leaks, attackers have complete database access regardless of RLS.
PostgreSQL RLS performance impact - is it slow?
RLS adds minimal overhead when policies are simple (auth.uid() checks). Performance issues come from complex policies with subqueries. For most apps, the security benefit far outweighs the negligible performance cost. Always use RLS for multi-tenant data.
Test Your RLS Policies
Find out exactly which tables are exposed before someone else does.
Get Starter ScanLearn More
Your privacy matters. We don't store any data you submit. Learn more