Developer reveals six data leak paths that bypassed correct Supabase RLS policies

A developer building a multi-tenant point-of-sale system on Supabase and Postgres discovered six distinct data leakage vulnerabilities over three security reviews spanning six weeks. Each leak slipped past Row Level Security policies that were technically correct as written, exposing gaps in the seams between Postgres privileges, RLS, and the PostgREST API layer. Key issues included default EXECUTE grants to PUBLIC on functions, column-level privilege asymmetries where new columns were writable but not readable by default, and SECURITY DEFINER views that unintentionally exposed write operations through PostgREST. One flaw silently allowed a browser client to reset an invoice counter, which could have produced duplicate entries in a tax invoice book. The developer shared specific fixes for each vulnerability, emphasizing that RLS alone is insufficient and that every new database object and column requires explicit privilege review for both reads and writes.