In February, I wrote about two Supabase apps that exposed far more than their developers intended. One gave me other users’ names and email addresses. The other let me read private messages and, with one curl command and a very sleepy mistake, take over its main community server.
Both teams fixed the issues. I kept finding the same kind of problem elsewhere.
At some point, manually opening JavaScript files, looking for a Supabase URL, and trying a bounded API request gets old. So I built a scanner. It started as a way to help me investigate these cases consistently. Now it’s open source on GitHub.
What it does
Give the one-off web scanner a site you’re authorized to test. It looks through the page and linked JavaScript for Supabase client configuration, discovers the exposed REST surface, and checks whether tables return a row to an anonymous request. It also has passive discovery adapters and Python scripts for larger research workflows.
The distinction I care most about is this: “a row came back” is a lead, not a vulnerability verdict.
Some apps deliberately make data public. A readable table does not prove RLS is disabled, and an empty response does not prove every authorization path is safe. You still have to understand the application, the role making the request, and whether that particular data was meant to be private.
The scanner keeps requests bounded and masks sample values by default. It does not use privileged keys it encounters. I wanted useful proof without turning a finding into a collection of somebody else’s data.
Why release it?
Because the Supabase publishable key being visible in JavaScript is normal. I still see people treat it like a leaked secret, while missing the more interesting question: what can a request using that key actually do?
The answer lives in grants, RLS policies, function permissions, and the difference between an anonymous request and a real user session. Those are easy boundaries to get wrong when you’re shipping quickly. I’ve done enough “wait, why did that return rows?” debugging to want a repeatable way to check.
I also wanted other researchers and developers to be able to inspect the tooling, challenge its assumptions, and improve it. The repository is MIT licensed. It has a web UI for one-off checks, a REST API, and Python scripts for discovery and research. It is not an installable command-line tool yet, despite my enthusiasm for making one.
Try it on something you own
The README has the local and Docker setup instructions. Start with an application you own or have permission to test. If it reports a readable table, check the data and application context before calling it a leak.
And if you find a real issue, collect the minimum proof, report it to the owner, and give them room to fix it. The goal is to get databases closed, not to see how much of one you can download.
The code, setup instructions, and contribution guide are here: Mrs-Skelli/supabase-scanner.
