Rule RLS1
Flags Supabase client table operations that commonly ship without RLS enabled on the table.
Tools · Supabase RLS
Check Supabase RLS and service-key exposure.
Vibe-coded and Lovable-style apps often call supabase.from(...).select without RLS discipline, or leak service_role into the browser. Release Check includes deterministic rules for these patterns (for example RLS1, RLS2).
What this check covers
Rule RLS2
Flags service_role / supabase_service patterns that must stay server-side.
Checklist CL08
Production checklist item: Supabase RLS enabled for relevant modes.
Example signal
// Pattern RLS1 looks for:
supabase.from('users').select('*')
// Pattern RLS2 looks for:
service_role / supabase_service in client bundles
In scope
- Static pattern detection on code you paste, upload, or scan via supported project/MCP paths
- Remediation hints such as enabling RLS and moving service keys server-side
- Local preview vs recorded/verified labeling when those workflows apply
Limitations
- Cannot confirm live Postgres policy state without an authorized environment integration
- May miss dynamic client construction or non-Supabase data layers
- Not a penetration test of your hosted Supabase project
Local result
Recorded result
Verified evidence
FAQ
Do you connect to my Supabase project automatically?
Not as an unauthenticated public URL scan. Use code/project workflows you authorize.
What if RLS is enabled but policies are wrong?
Pattern checks catch common missing-RLS and key-leak signals. Policy correctness still needs review and verification.