Supabase RLS Checker
Test your own Supabase project for tables your anon key can read with no Row Level Security blocking it.
Check your Supabase project
Paste your own project URL and anon (public) key — never a service_role key. This calls Supabase's REST API directly from your browser with the exact access level that key already has; nothing is sent to Draftbase.
How it works
This tool calls Supabase's own REST API (PostgREST) directly from your browser, using the exact key and access level you provide. First it reads the project's OpenAPI schema to list tables, then tries a one-row read against each one. A successful read means that table is reachable by that key with no RLS policy stopping it — the same access pattern an attacker with your public anon key would have.
This is a known, common gap: RLS left disabled by default is one of the most common Supabase misconfigurations, and it has caused real data leaks in apps built quickly with AI coding tools.
Skip building your own access rules
Draftbase separates a read-only, key-gated delivery API from an authenticated management API by design — there's no table to forget to lock down.
Hobby is free, no card. Startup is $49/mo when you outgrow it. The price is on the pricing page, where prices go.
No migration quarter, no kickoff workshop. Define a template and ship something today.
Frequently asked questions
What is Row Level Security (RLS) in Supabase?
RLS is a Postgres feature Supabase uses to control which rows a given API key can read or write. Supabase exposes every table over a REST API by default; without an RLS policy enabled, any request using that project’s anon key can read the full table — the API layer doesn’t add its own access control on top.
Is it safe to paste my anon key here?
The anon (public) key is meant to be public — it already ships inside your app’s browser bundle, so pasting it here exposes nothing new. Never paste a service_role key anywhere outside a trusted server environment; this tool refuses one if it detects the role claim.
A table shows "Reachable, no RLS block" — what do I do?
Enable RLS on that table in the Supabase dashboard (Authentication > Policies) and add a policy scoped to the access pattern you actually want — e.g. only rows owned by the authenticated user. A table with RLS enabled and zero policies denies all access by default, which is safe but often too strict for a real app.
Does a "Blocked" result mean the table is fully secure?
It means this specific key can’t read it — that’s the correct outcome for a properly scoped policy. It doesn’t check write access, service-role exposure elsewhere in your app, or policies for other roles, so treat it as one signal, not a full audit.
More free tools on the tools page, or read the headless cms guide on /headless-cms.