// paste SQL → instant check
Supabase security checker
Paste your schema, RLS policies, or migration and check it for the security holes that leak Supabase data — missing RLS, tables exposed to the public role, and over-permissive policies. Free, instant, and it runs entirely in your browser.
What the checker looks for
The same rules GuardLayer runs on every push, applied to the SQL you paste. Each finding comes with the exact line and the fix.
Tables without RLS
A public table created without ENABLE ROW LEVEL SECURITY is reachable through the Data API with no policy in front of it.
Granted to anon
An explicit GRANT … TO anon on a table with no RLS hands every anonymous visitor direct read/write access.
USING (true) policies
A policy with a USING (true) predicate matches every row for every caller — effectively no protection at all.
Policies not user-scoped
A policy whose predicate never references auth.uid() or auth.jwt() may expose far more than the current user's rows.
RLS disabled
DISABLE ROW LEVEL SECURITY on a table strips its last line of defense and makes it world-readable through the anon key.
Exposed keys & secrets
A service_role key or connection string committed in your SQL or config bypasses every policy you've written.
What a static checker can — and can't — do
This tool reads your SQL and flags misconfiguration patterns: RLS that's missing or disabled, grants that expose a table to the anonymous role, and policies that don't constrain rows to the current user. It runs in your browser, so it never sees your running database — it can't confirm a policy is correct for every user, only that the dangerous patterns above are present or absent. Treat a clean result as “no obvious footguns in this snippet,” not “provably secure,” and back it with real RLS tests.
Go deeper
Frequently asked questions
Is the Supabase security checker free?+
Yes — completely free, no signup and no credit card. Paste your SQL and get results instantly. The check runs entirely in your browser using the same engine that powers GuardLayer's repo scanning.
Does my SQL get uploaded anywhere?+
No. The checker runs the scan in your browser with client-side JavaScript, so the SQL you paste never leaves your device. Nothing is sent to a server, logged, or stored.
What Supabase security issues does it check for?+
It flags the common Supabase footguns visible in SQL: tables created without Row Level Security, tables or grants exposing data to the anonymous role, over-permissive USING (true) policies, policies that aren't scoped to the current user, RLS explicitly disabled, and secrets or service_role keys committed in code. GuardLayer runs 33 checks in total across Supabase and Next.js.
Can this replace testing my RLS policies?+
No — and it doesn't claim to. This is a static check: it catches misconfiguration patterns in the SQL you paste, but it can't see runtime behavior or prove a policy is correct for every user. Pair it with real RLS tests against your database.
Does it scan my whole project, or just a snippet?+
The checker grades the snippet you paste. To check your whole app — every table, policy, key, and API route — upload your files or connect the repo at /scan. GuardLayer is free for one repository and runs on every push once connected.
Is this a Supabase vulnerability scanner?+
It's a static scanner, which is a narrower and more honest description. It reads the SQL you paste and flags known misconfiguration patterns — missing or disabled RLS, over-permissive policies, anon exposure, tables granted without protection. It does not probe a running database, test credentials, or look for CVEs in your dependencies, so it won't find every class of vulnerability.
Can I use this as a Supabase security audit?+
Use it as the first pass of one. A full audit also covers your dashboard settings (leaked-password protection, MFA), your API keys, storage bucket configuration, and your application code — none of which this browser-based checker can see. Scanning the whole repository at /scan covers the code layer, and Supabase's own Security Advisor covers the database layer.
Is this the same as an RLS tester?+
No, and the difference matters. A tester runs your policies against real rows to prove who can see what. This checker reads the policy SQL statically and flags patterns that are wrong on their face — a policy with no user reference, a USING (true), a table with RLS never enabled. Static catches the obvious holes in seconds; testing proves correctness. Use both.
Check the whole app, not just a snippet
Upload your files or connect the repo, and GuardLayer scans every table, policy, key, and route — then runs on every push. Free for one repository.