Supabase security audit & penetration testing
A Supabase security audit checks that Row Level Security (RLS) is enabled and correct on every exposed table, that your anon and service keys aren't over-privileged, and that Storage, Edge Functions and Realtime never leak one user's data to another. Sintropyc tests this by actually signing in as different users and trying to reach each other's data.
What a Supabase audit actually covers
Supabase is Postgres with an auto-generated API in front of it. That is powerful, but it means your database is one misconfiguration away from being public. A real audit looks at every layer that can expose data:
- Row Level Security (RLS) — enabled and correct on every table exposed through the API, including views and functions
- Exposed schemas — tables reachable through PostgREST that were never meant to be public
- Key scope — the anon key limited to what an anonymous visitor should do; the service-role key never shipped to the browser
- Storage buckets — object policies that stop one user downloading another's files
- Edge Functions — server-side authorization, not just a valid session
- Realtime — channel authorization so subscriptions don't stream other tenants' rows
Why RLS gaps are the number-one Supabase risk
Supabase itself warns that RLS must be enabled for any schema exposed through the API — a table without a correct policy is readable and often writable by anyone with the public anon key. The failure is quiet: the app works perfectly for the owner, so nothing looks wrong until someone changes an id and reads a stranger's record.
Apps generated quickly — with Lovable, Bolt, v0 or a weekend of vibe-coding — very often ship with RLS off or a policy that checks the wrong column. The frontend hides the data; the API does not.
How Sintropyc tests it
Sintropyc is an autonomous AI penetration testing agent. It signs in as real users across different roles, drives your product the way a customer would, and proves every finding with a working exploit — never a scanner guess. Each finding is checked by a human before it reaches you, comes with the exact fix, and is attacked again after you ship it to confirm it held.
For Supabase specifically, Sintropyc creates or uses two real accounts, authenticates as each, and walks the exposed API — reading and writing rows, listing buckets, calling functions and opening realtime channels — trying to cross the line between the two users. When it can read account B's data while signed in as account A, that is the proof: a concrete request and the data it returned, not a maybe.
What you get
- Every exposed table, bucket, function and channel with a verdict
- A working exploit for each real finding — the request and the data it leaked
- The exact policy or config change to close it
- A retest after you ship the fix, to confirm it actually held
Common questions
Is this just an RLS linter?
No. Linters and Supabase's own advisor flag tables with RLS disabled — useful, but they can't tell whether a policy is correct. Sintropyc actually authenticates as different users and proves whether one can reach another's data.
Will it touch production data?
It runs read-only by default and in an isolated way; any change needs an explicit go-ahead. Findings are demonstrated with the smallest safe proof, never a destructive action.
Can I hand the report to a customer or auditor?
Yes. Every finding is human-reviewed before it reaches you and comes with a proof screenshot, an impact statement and a fix — suitable for an enterprise customer or a SOC 2 auditor.