vibe-check-rls
v0.1.0
Published
Read-only RLS audit for Supabase projects. Uses the public anon key to enumerate tables that leak data to unauthenticated users — exactly what a curious attacker would see.
Downloads
131
Maintainers
Readme
vibe-check-rls
Read-only RLS audit for Supabase projects. Uses the public anon key to enumerate tables that leak data to unauthenticated users — exactly what a curious attacker sees on page load.
npx vibe-check-rls --url https://<project>.supabase.co --anon-key eyJ...MIT licensed. Node 18+. No dependencies.
What it does
The Supabase anon key ships in your client bundle by design. It represents the unauthenticated user. RLS policies decide what that user can read.
This tool acts as anon and reports which tables return rows or schema info to it:
[CRITICAL]Anon can read PII (email, password_hash, stripe_customer_id, etc) or the table name implies sensitivity (users, payments, sessions)[HIGH]Anon can read rows from a generic-looking table (verify every column is meant to be public)[MEDIUM]PII-flavored table is queryable but returns no rows (RLS may filter, but schema exposure tells an attacker what to target with stolen credentials)[LOW]Generic table is anon-queryable but empty[INFO]Anon got a 401/403 — RLS doing its job
What it does not do
- No auth bypass attempts
- No mutations (no INSERT/UPDATE/DELETE)
- No service-role-key usage (that key should never be public — if it leaks, that's a separate finding from a different tool)
- No RPC function probing (out of scope for v0.1)
- No rate-limit hammering (250ms pause between probes)
Why it's defensible
The anon key is publicly distributed by intent — your frontend ships it on every page load. Using it as anon to enumerate what unauthenticated users can read is the same operation your frontend performs on every page load, just systematic.
The tool refuses to run non-interactively without --i-have-permission to keep the consent gate explicit.
Usage
# Pretty output
npx vibe-check-rls --url https://abc.supabase.co --anon-key eyJ...
# Just the worst finding
npx vibe-check-rls --url https://abc.supabase.co --anon-key eyJ... --top
# Full JSON
npx vibe-check-rls --url https://abc.supabase.co --anon-key eyJ... --json
# Via env vars
SUPABASE_URL=https://abc.supabase.co \
SUPABASE_ANON_KEY=eyJ... \
npx vibe-check-rlsWhat it can't catch
RLS bugs that need a real session to trigger: broken UPDATE/DELETE policies, RPC function bypass, JWT replay, business logic that runs as service-role on the wrong code path. Those need a logged-in session and manual review.
That's the Vibe Audit.
Companion tool
vibe-check-recon — public-surface security recon for AI-built apps. Catches .git/ exposed, .env leaked, source maps in production, weak CSP, public buckets. Pair them: recon for the network surface, rls for the database surface.
