What it is
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.
How it happens
Supabase exposes tables in the public schema through its REST API, and the anon key that ships to browsers can call it. Row Level Security is what stops that key from reading and writing every row. A table created in a SQL migration does not get RLS unless the migration turns it on, so a missing `enable row level security` line leaves the table open from the moment the migration runs. The report names each table and the migration file and line that created it.
What an attacker gets
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 reports
What FixVibe reports
Runs when you connect a GitHub repository, on Pro and above. Each finding shows the file and line, its severity and fix steps you can paste into your AI coding tool.
How to fix it
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.