supabase-multi-tenant-rlslisted

Design, implement and verify multi-tenant Row Level Security in Supabase Postgres - organizations, memberships, roles and invites - without recursive policies, privilege escalation, or silent cross-tenant leaks. Use this whenever the work touches organizations, teams, workspaces, tenants, members, invites, roles and permissions, RLS policies, security definer helper functions, or any table carrying an org_id or tenant_id. Use it for audits and debugging of existing policies too. Reach for it even when the request sounds like a trivial "just add a policy" task, because the failure mode here is silent, a wrong policy returns rows instead of an error.
tanfust/skills · ★ 0 · API & Backend · score 70

Install: claude install-skill tanfust/skills

# Multi-tenant RLS on Supabase Most RLS mistakes do not throw. They return the wrong rows, or accept a write that should have been rejected, and nobody notices until a customer sees another customer's data. So the work is not finished when the policy is written. It is finished when a cross-tenant read has been proven to return zero rows. This skill covers the org / membership / role shape used by B2B SaaS. For single-user-owns-the-row apps, a policy of `user_id = (select auth.uid())` is enough and none of this is needed. ## Order of work Follow this order. Each step depends on the one before it, and the verification step is not optional. 1. Fix the tenancy shape 2. Write the schema declaratively 3. Write the helper functions 4. Write the policies, per table, per command 5. Handle the two dangerous tables: memberships and invites 6. Run the audit and the cross-tenant test ## 1. Fix the tenancy shape Answer these before writing SQL, because changing them later means rewriting every policy: - Can a user belong to more than one organization? (Usually yes. If yes, the org cannot live on the user row.) - Is there a role hierarchy, and what is the minimum set? Start with `owner`, `admin`, `member`. Do not build per-resource permissions until a customer asks. - Can an organization contain sub-units (projects, teams) with their own access rules? If yes, decide now whether policies check org membership or unit membership. Mixing both later produces policies nobody can reason ab