Skip to content

Scan rule · RSC-SEC-098

Database wide open (composite)

SecuritySeverity: CriticalCWE-284OWASP A01-2021

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

External scan (anonymous)Source code from source mapsRepo access (deep scan)

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.

Scan your own app for free