L'accroche
Supabase's anon key is meant to ship to browsers. The database boundary is Row Level Security. When a migration creates a public table and never enables RLS, the app is relying on route handlers and client code to remember authorization forever.
Comment ça marche
The repo check parses SQL migration files, records `CREATE TABLE` statements for public-schema tables, and verifies each one has a matching `ALTER TABLE ... ENABLE ROW LEVEL SECURITY` statement somewhere in the repository. Non-public Supabase schemas such as `auth`, `storage`, and `realtime` are ignored.
Le rayon d'impact
A missing RLS migration may not leak data on day one, but it removes the database-enforced guardrail before the table starts holding user records, billing data, profile data, or internal workflow state. Once the table is exposed through Supabase's REST API, the public anon key becomes enough to test it.
// what fixvibe checks
What FixVibe checks
FixVibe repo scans look for high-confidence security patterns and dependency risk in source context. Reports identify the affected area and recommended fix. For check-specific questions about exact detection heuristics, active payload details, or source-code rule patterns, contact support@fixvibe.app.
Défenses blindées
Add a follow-up migration for each affected table: `alter table public.<table> enable row level security;` and usually `alter table public.<table> force row level security;`. Then add least-privilege policies for each operation the app needs, scoped by `auth.uid()` or by server-only service-role routes. For sensitive server-only data, prefer a non-public schema.