I built this, so weigh my enthusiasm accordingly. It’s free and MIT licensed. I’m not a programmer: I’m a product owner in South Africa who builds by directing Claude Code. Why I run my own rental-management app on Supabase. The question that worried me: can one of my customers see or change another customer’s data? Row level security is easy to get wrong, and I can’t read the policies well enough to be sure. So I had Claude Code build something that checks by trying, not by reading. What it does tenant-leak-check rebuilds your app’s database on your own machine from your migration files (Docker, local only; it refuses anything that isn’t a local address and needs no keys). It creates two made-up customers with made-up data. Then it really attacks, as customer A and as a visitor who isn’t signed in: tables: read, add, change, move a row to the other customer, delete storage: list, download, upload, overwrite, delete the other customer’s files database functions: called with customer B’s ids You get an HTML, Markdown and JSON report with the evidence (what was sent, what came back) and a plain-English fix for each leak, plus exit codes so CI can fail the build. Migration mode runs the app before and after a new migration and flags new leaks and risky changes: policy removed, RLS switched off, column dropped, with line numbers. There’s also a Claude Code skill: you say “run the leak check” and it runs it and explains the report. What I checked it on A demo app with 19 planted leaks: it finds all 19. That’s 48 failed checks, none missed, none extra, and the tests require an exact match. The fixed version of the same app comes out clean. My own rental-management app: 669 cross-customer checks, 0 leaks, plus 3 smaller findings worth fixing. A deliberately bad migration I made up for that app: 6 new leaks and 4 flagged lines. How Claude Code was used Claude Code (Opus 5.5) did all the building, in four sessions. I wrote the brief and the rules: local only, never weaken a test, and a check can never “pass” unless it was really carried out; otherwise it must say “not tested” or “unclear” and give the reason. The planted-leak demo was the key part, because it showed the tool catching what it claims to catch. Limits It’s an automated isolation test, not a security certification, audit or penetration test. “0 leaks” means none found in what was tested. It tests a local copy built from migration files, not your live database. Anything changed by hand in production is invisible to it. It doesn’t test your app code, Edge Functions, anything using the service-role key, Realtime or webhooks. Two made-up customers with a few rows each, so rules that depend on lots of data may not get exercised. Database functions are called once with automatic arguments. If one refuses because the input was invalid, the report says so, and what it does with a realistic request isn’t proven. Needs Node 24, Docker and the Supabase CLI. Early version (0.1.0), only tried on the demos and my own app. Try it https://github.com/seanjohnson-dev/tenant-leak-check The README walks through it step by step, and the demo apps run in a few minutes. If you’d rather have me run it on your project and explain the report, message me. More about what I do: https://swjdigital.com/ A question If you run a Supabase app with more than one customer: which leak shapes should it try that it doesn’t? And if it gets something wrong on your project, tell me. submitted by /u/Its_about-tech
Originally posted by u/Its_about-tech on r/ClaudeCode