Supabase RLS checklist for AI-built apps (2026)

Updated 2026-10-25 · Trustfield

Short answer: the anon key is public. Your data is safe only when every table and storage bucket has RLS enabled plus a policy that limits rows to the right user. If a table has no policy, the API returns nothing — that is fine. If RLS is off, the API returns the table.

The checklist

1. RLS on for every table in the public schema, including join tables and audit logs.
2. A policy exists for each operation you need (select/insert/update/delete). “RLS enabled but no policy” blocks everything — fine for a private table, broken for your own reads.
3. Policies filter by the user, for example using (auth.uid() = user_id), not just using (true).
4. Storage buckets need policies too. A public bucket is public forever, including old uploads.
5. service_role never reaches the client. It bypasses RLS. Server-only.
6. Security-definer SQL functions need a fixed search_path and an explicit permission check; otherwise they become a public RPC.
7. Views created with security_invoker = false run as the owner and can bypass RLS — check them.
8. Test with the anon key, not the dashboard. The dashboard uses a privileged connection and hides the problem.

Test it in 60 seconds

Paste your project URL and anon key into the free checker: /tools/rls. It lists tables and shows which ones return rows to the public key. For the full report — keys in your bundle, webhooks, AI prompt injection — run the free scan.

Trustfield is an external, read-only review. Not a penetration test and not a certification. Methodology · Security