Security audit of an AI-generated Supabase backend

The problem

A US PropTech startup was shipping a backend that was largely AI-generated toward production without a security review. The team had moved fast on features, but nobody had systematically checked whether the row-level security policies protecting each tenant's data actually held up under the access patterns the application generated.

What I built

I ran a structured security audit of the Supabase backend, focused on multi-tenant isolation: how RLS policies were scoped, how storage buckets were secured, and where privilege could escalate beyond what a given role should hold. I delivered the work in two steps deliberately — a findings report first, then a separate remediation pass — so the client could see and prioritize the risk before any fixes touched the running system.

The audit surfaced four critical findings, including unprotected storage buckets, privilege-escalation paths in generated RLS policies, and a cross-tenant write vulnerability where one tenant could write into another tenant's data. That last one is the kind of bug that doesn't show up in normal testing because every test account behaves itself — it only surfaces when you deliberately try to cross a boundary the policy was supposed to enforce.

Outcome

All four findings were remediated and tenant isolation was closed before the affected paths went live. The report-then-remediate structure meant the client had a clear, prioritized view of risk before any code changed, rather than a single bundled patch with no record of what had been wrong.

Why it mattered

AI-generated backends tend to get the happy path right and the boundary conditions wrong, because that's exactly where generated code is weakest — the parts that require reasoning about what a malicious or merely curious user could do, not what a well-behaved one will do. A cross-tenant write is the kind of finding that's cheap to fix in a review and very expensive to discover after launch.