Supabase Row Level Security Policy Set

Design Row Level Security for a Supabase Postgres project so a user cannot read or write another tenant's rows, including through joins. APP Product: [PRODUCT] Tenancy: [USER OWNS ROWS | ORG WITH MEMBERS | BOTH] Tables (name, important columns, who should read, who should write): [PASTE SCHEMA OR LIST] Roles in auth.jwt(): [LIST — e.g. authenticated, plus org role claim] Service role paths that must bypass RLS: [WEBHOOKS | MIGRATIONS | NONE] Storage buckets involved: [BUCKETS OR NONE] DELIVER 1) Threat list: 8 concrete leaks (select via a foreign key, insert with someone else's org_id, update a role column, storage object URL guessing, RPC defined as security definer, realtime subscription). Mark which your policies close. 2) SQL for each table: - ENABLE ROW LEVEL SECURITY - separate policies for SELECT, INSERT, UPDATE, DELETE - WITH CHECK on writes, not only USING - helper SQL function is_org_member(org_id) as security invoker, with why you chose invoker vs definer 3) A policy that blocks users from changing their own role or org_id. 4) Tests as SQL: for user A and user B, the select/insert that must succeed and the one that must return zero rows or error. Use set request.jwt.claim.sub. 5) A note on views, security_barrier, and any table you intentionally leave without RLS — those need a comment that says why. 6) Storage policies if buckets were listed, matching the same tenancy key. Do not suggest disabling RLS for "just the admin UI." Admins go through a checked claim or a server route with the service role, and you will show that route's authorization check in pseudocode. Assume the anon key is public.