← ClaudeAtlas

rls-auditlisted

Authorized defensive security audit of a Supabase project you own — anon-key exposure, RLS gaps, service-role logging. Use for "what's exposed with the anon key", "rls audit", "security audit the backend".
danielimad/SKILLS · ★ 0 · API & Backend · score 54
Install: claude install-skill danielimad/SKILLS
# RLS Audit — authorized self-audit **Precondition: the user owns the project being audited.** This is defensive security against your own infrastructure — confirm the project ref belongs to the user before starting. Do not run this against a third party's project. Parity partner: /rls-enforce. This skill finds and reports; that one closes the gaps. ## Sweep 1. **Enumerate the anon surface**: every table, view, RPC, storage bucket, and edge function reachable with the public anon key (REST catalog + storage list + functions list). 2. **Test as anon**: read/insert/update/delete attempts against each surface — read-only where possible; any write test uses throwaway rows that are rolled back/deleted immediately. 3. **Test as a self-registered user**: sign up a scratch account, repeat the sweep — cross-tenant reads are the killer (can user A see workspace B's rows?). 4. **Edge functions**: which are world-callable? Do they verify JWT + ownership INSIDE the function? This matters most when functions are deployed with `--no-verify-jwt`, which moves auth from the platform into your code. Check for module-level caches that can bleed across tenants on warm instances — a per-tenant value cached at module scope gets served to whoever hits that instance next. 5. **Service-role hygiene**: service-role actions must be logged with full detail; flag unlogged service-role paths and missing audit tables. ## Output — the findings (the handoff to /rls-enforce) This skill FINDS; it does not f