Supabase | The Postgres Development Platform

Free checker for cross-tenant data leaks in Supabase apps

Security

Auth

Database

Next.js

I kept finding the same three mistakes in Supabase projects built with AI tools:

a table with RLS never enabled, so the anon key reads every row
a route that uses the service role and filters only by an id from the URL
a SECURITY DEFINER function without an auth.uid() check that anon can call

Audit AI reads your migrations and Next.js routes and flags these. For a flagged finding it can run a sandbox: a local Supabase with your migrations, two test users in different tenants, network off. It tries the attack, applies the suggested migration and tries again.

You can try it on a demo app with three planted holes: open https://auditai.sh and paste github.com/audit0/auditai-playground.

The scanner is open source: github.com/audit0/auditai-scanner (npx auditai-scan .). Precision on repos it had never seen was 36% on a blind sample, published at auditai.sh/stats, so expect false positives. I would like to hear about the ones you hit.

How to help

AuditAI_sh introduces a tool that identifies common security issues in Supabase projects, such as missing RLS and insecure functions. The tool simulates attacks in a sandbox environment and suggests fixes. Another user, PeterBuildsSecure, suggests additional security checks and questions the tool's precision rate.

Help on Reddit

Replies (1)

Those three are the right starting set, but two more are worth adding since they slip past exactly this kind of check:

Table-owner / FORCE ROW LEVEL SECURITY bypass. RLS is enabled but the query runs as the table owner (or another BYPASSRLS role) -- a migration diff or "is RLS enabled" check won't catch this because the policy itself is fine, it's just not enforced for that connection.
Permissive policies that OR together. Two independently-reasonable policies (e.g. one scoped to owner, one scoped to "shared" rows) can combine into a hole neither has on its own, since Postgres ORs permissive policies rather than ANDing them.

Both are invisible if you're just reading migrations for missing/malformed RLS -- you need to check pg_policies + relforcerowsecurity + role privileges against a live connection, not the SQL text.

Also curious about the 36% precision number -- is that mostly false positives on the SECURITY DEFINER check (hard to tell "calls auth.uid()" from "actually gates on it") or something else? That's low enough to be interesting on its own.

PeterBuildsSecure·9/15/2026, 2:49:04 PM