rls-guard

Did I set up my Supabase right? A 10-second ship-readiness check for your backend.

rls-guard is an MCP server. You point it at your own Supabase project and it tells you — in plain language — whether any of your tables are readable by anyone on the internet, then hands you the exact SQL to lock them down.

It uses your project's anon (public) key the same way a browser does. That key already ships inside every app built on Supabase, so this is simply checking what the world can already see — before you find out the hard way.

Built for vibe coders shipping on Supabase + Next.js. No dashboards, no signup — your AI assistant runs it for you.

Why this exists

When you build on Supabase, every table is reachable through an auto-generated API. Row Level Security (RLS) is the lock. If you forget to turn it on — or your AI scaffolded a table without it — that table is wide open to the public anon key. This is the single most common way vibe-coded apps leak their users' data (emails, tokens, whole user tables) within days of launch.

rls-guard answers one question before you ship: "Did I leave any doors open?"

Install

Add it to your MCP client (Claude Desktop, Cursor, Windsurf, etc.):

{
  "mcpServers": {
    "rls-guard": {
      "command": "npx",
      "args": ["-y", "rls-guard-mcp"]
    }
  }
}

That's it — no global install. Restart your client and your assistant can now run the check.

Use it

Just ask your assistant:

"Check my Supabase is safe to ship."

It needs three things — your assistant fills in the table list itself by reading your supabase/migrations or generated types:

| Input | Where | Notes | |---|---|---| | project_url | Dashboard → Settings → API → Project URL | e.g. https://abcdEXAMPLE.supabase.co | | anon_key | Settings → API → Project API keys → anon public | A public client-side key. Safe to use. | | tables | your migrations / generated types / schema | e.g. ["profiles","posts","messages"]. Modern Supabase blocks anon schema introspection, so the table list is supplied. Each table is checked for both anon read and anon insert exposure. | | rpcs (optional) | your migrations / generated types | e.g. ["reset_password"]. Checks whether the anon key can call these database functions. |

What you get back

Severity is weighted by what's actually exposed, so you don't get cried wolf at for a table that's meant to be public:

🛡️ rls-guard — Supabase ship-readiness check
Result: 🔴 1 critical · 🟠 0 high · 🟣 1 write-exposed · 🟡 1 confirm · 🔵 1 public-by-design · 🟢 5 ok

🚨 1 table is leaking real data to the public. Lock it down before you ship.

🔴 CRITICAL — public.profiles
- Readable by the public anon key — 1,204 rows visible.
- Looks like user/account data.
- Sensitive columns: email (email (PII)), stripe_customer_id (billing identifier).

  alter table "public"."profiles" enable row level security;

🟣 WRITE_EXPOSED — public.waitlist_signups
- Anon can INSERT into this table.
- Read access isn't a concern, but anon can INSERT into this table — anyone can create rows in it.

  revoke insert on "public"."waitlist_signups" from anon;

🔵 INFO — public.published_posts
- Readable by the public anon key — 50 rows visible.
- Publicly readable, and the name suggests that's intentional. Confirm it exposes no private columns.

---
🧩 RPC functions checked (1)
⚠️ 1 function(s) are callable by the public anon key.
- `admin_reset_all_passwords` — Callable by the public anon key. Confirm it's not SECURITY DEFINER exposing privileged data/actions, or restrict it to the `authenticated` role / its actual owner.

Paste the fix SQL into your Supabase SQL Editor, run it, and re-run the check to confirm.

| | Means | |---|---| | 🔴 CRITICAL | Anyone can read it and it holds sensitive data (PII, secrets, billing) — a real leak. | | 🟠 HIGH | Anyone can read it. If that's not intended, lock it down. | | 🟣 WRITE_EXPOSED | Read access is fine, but anon can INSERT rows into it. | | 🔵 INFO | Readable, but named like public-by-design content and nothing sensitive — probably fine. | | 🟡 CONFIRM | Sensitive table, no rows visible right now — confirm RLS is on before it has data. | | 🟢 OK | The anon key can't read or write it. |

A table that's already CRITICAL or HIGH and also accepts anon inserts keeps its read severity, with an extra note and an insert-aware fix SQL block — write exposure is never buried under a read finding.

What it checks now

• ✅ Which tables the anon role can actually read — a true black-box probe, with live row counts (it catches permissive policies, not just "RLS off")
• ✅ Which tables the anon role can actually INSERT into — a dry-run probe (empty payload + PostgREST's tx=rollback) that reads the Postgres error code to tell "blocked" (42501/401/403) apart from "got past the auth check" (a constraint error, or even success) — no row is ever actually written
• ✅ Which RPC functions are callable by the anon key, via an OPTIONS probe that never executes the function body
• ✅ Severity weighted by sensitivity — users, emails, tokens, API keys, billing, PII
• ✅ Tells intentionally public apart from accidentally public
• ✅ The exact SQL (RLS, grants, or both) to fix each finding

On the roadmap: Storage bucket policies, auth settings — plus continuous monitoring and a CI gate so a misconfigured table can't reach production.

Client-facing report (HTML + PDF)

The same scan can be turned into a polished, plain-English report a non-developer can read — an executive summary line, each finding ranked by severity with a colored badge, what it is, why it matters (the business risk, in one sentence), the exact fix, and a disclaimer footer. It's a presentation layer only — it reuses the existing scan and never changes how the scan works.

# 1) Preview the design with built-in sample data (no network):
npm run report -- --sample

# 2) Run a fresh scan and generate the report (keeps the anon key out of shell history):
RLS_PROJECT_URL=https://abcdEXAMPLE.supabase.co \
RLS_ANON_KEY=eyJ... \
RLS_TABLES=profiles,posts,messages \
RLS_RPCS=admin_reset_all_passwords \
npm run report

# 3) Or render a previously saved scan result (an AuditReport JSON):
npm run report -- --input result.json

Output lands at a predictable path:

reports/rls-guard-<project>-<timestamp>.html
reports/rls-guard-<project>-<timestamp>.pdf
reports/latest.html   reports/latest.pdf   ← always the newest scan

Useful flags: --title "..." (the report title; defaults to a plain, unbranded "Supabase Security Report"), --no-pdf (HTML only), --out-dir <dir>.

PDF rendering uses puppeteer — a devDependency only, so it is not shipped to people who install the MCP server; it's tooling for generating reports. It renders the PDF from the exact same HTML, so the two always match. On a machine where Chrome/Chromium is already installed, set PUPPETEER_EXECUTABLE_PATH to reuse it instead of Puppeteer's bundled browser. Use --no-pdf to skip PDF entirely.

Is this ethical / safe?

Yes. It's a self-check: you run it against a project you own, using a key that is already public by design. It performs non-destructive probes only — read probes never modify data, and insert probes use an empty payload plus PostgREST's Prefer: tx=rollback, so no row is ever actually written, even on tables with no required columns. RPC checks use OPTIONS, which never executes the function. It is not a tool for poking at other people's apps.

License

MIT