Software teams on Supabase with paying customers

Answer the customer data isolation question, with evidence you can stand behind.

Can one customer see or change another customer's data? An independent, fixed-scope engineering review of your Supabase row-level security, functions, grants, auth claims, storage and keys, run against a copy you control. Written findings, fix drafts you can merge yourselves, and a summary for your customer's security team.

A clear answer for your customer's security team
Prioritise the fixes before the next big deal asks
Be the team that checked customer data isolation first

Did you know?

A careful team can revoke a function from PUBLIC and still leave it callable

revoke execute on function get_report() from public;

Who can still call it?

PUBLICrevokedthe grant you removed
anonstill allowedanyone using your public API key
authenticatedstill allowedany signed-in user

Supabase gives each new function its own grants to these roles, so revoking from PUBLIC leaves them in place. That is the platform default as we found it, and Supabase may change it.

We found this in our own product, more than once. Supabase's security advisor flagged it, we sealed it the next day, and our own checks now catch it automatically.

You receive written findings with a fix draft for each, ranked by severity, with who could exploit each one, how we confirmed it, and which flags from an automated scan are not real issues, plus a summary for your customer's security team. You also get the grant check we run on our own code, set up for your repository, a plain-language call to walk through it all, and a re-check of critical fixes. An engineering review of a copy you control: not a penetration test, certification, attestation or implementation work.