Scan rule · RSC-SEC-098
Database wide open (composite)
Combines what would be explainable in isolation: the access key in shipped code, missing or permissive Row Level Security and — for the critical tier — writes straight from the browser.
Why this matters
The anon key in the bundle is by design with Supabase, a migration without RLS is a hint, an insert from the browser is an architecture pattern. Each on its own reads as “worth a look”. Together they mean something else: any visitor can read and write what the application stores using the public key — no login, no trace.
This exact combination appears regularly in AI-built apps because the generator sets up the database so the prototype works immediately. It works precisely because nothing checks. The finding names its components with evidence so the claim can be traced.
The way out is not a rebuild: enable RLS per table, bind policies to `auth.uid()`, review write paths. Then test every table with the public key and no login — if nothing comes back, the door is closed.
Scan tier
How to fix it
Enable Row Level Security on every affected table, set per-user policies per operation and move browser write paths behind a server-side check.