Supabase RLS check for AI-built apps
To check Supabase RLS, make sure every table in the public schema has RLS turned on, then read each policy to see who it lets in. A table with RLS off can be read by anyone who has your public anon key, and that key is in your site's JS. AI tools often make tables quickly, so it is easy to miss one.
Step-by-step checklist
- In the Supabase dashboard, open Table Editor. Any table marked as RLS disabled needs a fix.
- Or run this in the SQL editor:
select tablename, rowsecurity from pg_tables where schemaname = 'public'; - Turn RLS on where it is off:
alter table my_table enable row level security; - Read every policy. Watch for
using (true)or policies for theanonrole on private data. - For user data, limit rows to the owner, for example
using (auth.uid() = user_id). - Check insert and update policies too, with
with check, so users cannot write rows as someone else. - Test with two accounts. One should not see the other's rows.
- Check views and functions. Views and
security definerfunctions can skip RLS if you are not careful.
Supabase also has a Security Advisor in the dashboard. It flags tables without RLS. Run it after each big change.
FAQ
What happens if RLS is off?
Anyone with your anon key can use the Supabase API to read, and maybe change, that table.
Is RLS on enough?
No. RLS on with no policies blocks everyone. RLS on with a loose policy can still let everyone in. The policies matter.
Does the service_role key follow RLS?
No. It skips RLS. Keep it on the server only.
Can DeployVet test my RLS?
The Free check tests from the outside with your public key. The $7 Scan adds a read-only look at your Supabase project.
Check your app for free
DeployVet scans your live site from the outside, like a stranger would. You get a score and the worst issue with a fix.
DeployVet has three plans. The Free check is $0. A one-time Scan is $7. Pro is $15/mo and adds weekly scans and email alerts. For paid plans you pay first, then the scan runs.