RLS Audit

On a BaaS, the database is the API. The public key ships inside your JavaScript bundle, so anyone can send any query your grants and policies allow. This skill finds the gap between what you meant to expose and what the database actually permits.

Analogy: RLS is the bouncer at each door of a building. This skill doesn't ask the bouncer whether they're doing a good job — it walks up to every door with a visitor badge and tries the handle.

Why a scanner is not enough

A generic scanner greps for USING (true) and flags it. That is wrong in both directions: a public price list is supposed to be USING (true), while a policy that looks strict (customer_id = auth.uid()) can be useless if the user is the one who writes customer_id. The scanner has no way to know what you intended. Intent is the missing input, and you have to declare it. That declaration is Step 1.

Scope

Postgres reachable through PostgREST-style auto APIs: Supabase, InsForge, Neon + PostgREST. The role names below (anon, authenticated) are the common ones — confirm yours. It does not apply to MySQL, MongoDB or Firebase rules.

This is a focused review, not a penetration test. For an app holding money or sensitive data, it is the step before a professional audit, not a substitute for one.

Step 1 — Declare intent (once, in writing)

Classify every table and view into exactly one bucket. Ask the developer; do not guess from names. Save it as docs/rls-intent.md so the next audit starts from it.