Supabase Exposure Scanning is Now Built into Attack Surface Management
TL;DR: Oneleet now discovers your Supabase attack surface and tests what an attacker can actually do, going beyond just policy linting that Supabase Database Advisor covers.
Your Supabase publishable key is public by design. Your private data should not be. The real security boundary is the access enforced across your tables, functions, and storage. Proper row-level security (RLS) is an important part of securing your data, but having RLS configured properly alone is not enough. Overly broad policies, excessive grants, exposed functions, and storage misconfigurations can still expose or modify your data.
To truly protect your data, you need to go a step further — and that’s where Supabase Exposure Scanning comes in. Supabase Exposure Scanning is now built directly into Oneleet's Attack Surface Management (ASM), and it runs automatically — no setup required; no connecting a second tool. Here’s what you need to know about this new feature.
How Supabase Exposure Scanning Works
Let’s dig into the details behind what Exposure Scanning actually does.
It finds your Supabase footprint on its own
ASM crawls your applications' JavaScript and pulls out every Supabase project, key, table, function, and storage bucket referenced anywhere in your code. Each one lands in your asset inventory under Backend as a Service, tied to the apps that actually use it. You don't have to tell it where to look.
It finds what a schema dump wouldn't
Recently, Supabase shut off anonymous access to its OpenAPI schema, which is the shortcut a number of scanners rely on. So, we rebuilt discovery around application references, GraphQL, storage metadata, database error messages, and targeted resource-name probing instead. That makes it possible for us to uncover real, application-level exposure.
It tests like an actual attacker would, twice
Every resource gets tested with no account at all, and then again as a normal signed-up user if public signup is open. That second pass makes a difference: Plenty of data isn't reachable by a stranger off the street but is wide open the moment someone clicks "sign up" — which is exactly what an attacker would do.
It shows its work
Every finding (e.g., an unauthorized read or write, an exposed function, a bucket you can list or write to, private data a policy quietly made public, a privileged key sitting in client-side code) comes with the affected resource, evidence, a reproducible curl command you can run yourself, and automated retesting so you know when it's actually fixed.
What We Found During Initial Scans
We scanned more than 300 Supabase instances and found several vulnerability patterns that could allow an attacker with no access to reach sensitive internal data or user data. Below is a summary of our findings, but if you’d like a full breakdown, check out this article.
- RLS being disabled was only 25% of the problem. The other 75% of vulnerabilities involved a twist on that basic misconfiguration, or had nothing to do with RLS at all.
- The "obvious" check (public schema) only caught a third of it. Testing the public schema with just the publishable key surfaced 33% of findings. The rest required testing every exposed schema, an authenticated (not just anon) role, and both column-level and row-level access.
- 125 tables opened up the moment we created an account. They were locked to the publishable key, but "authenticated" isn't the same as "authorized." Plenty of apps stopped checking after login.
- 20 vulnerable tables lived outside the
publicschema. Custom schemas rarely get the same RLS scrutiny, but a common setup snippet grants access to every table in a schema, present and future, in one shot. - 13 tables blocked
select *but leaked data through named columns. SELECT had been revoked at the table level, then quietly re-granted on individual columns. - 98 tables were writable with no read access at all. Grants and policies apply per operation. A locked-down SELECT says nothing about INSERT, UPDATE, or DELETE.
- Open registration was the door, even on "internal" apps. CRMs, training portals, and task trackers with no visible signup page still allowed
/auth/v1/signupcalls directly, bypassing frontend-only domain checks and even some backend hooks that failed open on unrecognized domains. - Storage buckets leaked the same way tables did. Overly broad SELECT policies made buckets listable and downloadable with just the publishable key; open INSERT policies accepted uploads into any path, including one case where an uploaded SVG became stored XSS on the company's own domain via a custom hostname.
How to Get Started with Supabase Exposure Scanning
Supabase Exposure Scanning runs inside the ASM scans you're already doing — no additional action required. Connect your domains, and your Supabase projects show up in the first scan. Assets show up under Attack Surface → Assets → Backend as a Service. Vulnerabilities show up under Issues.
You don't get a report saying your policies exist. You get a report saying what someone could actually do with them.
Happy scanning!
Head of Technology, Security and Compliance
Product Manager