Hey everyone,

Whenever I build multi-tenant setups on Supabase, relying on app-level middleware or tossing WHERE org_id =x inside Next.js Server Actions always feels risky. It works fine until someone forgets a filter on a late-night commit and leaks tenant data in prod.

I pushed isolation directly down to Postgresusing custom JWT claims in RLS, then wrote an integration test runner to try and break it.

Here’s the baseline setup:

1. Custom Claims RLS Pattern

Instead of running a subquery against org_memberships on every single row query, we pass org_idinside the Supabase session JWT claims.

The policy pattern for workspace tables:

SQL

create policy "Enforce organization isolation"
on public.workspace_data
for all
using (
  org_id = (auth.jwt() -> 'app_metadata' ->> 'org_id')::uuid
)
with check (
  org_id = (auth.jwt() -> 'app_metadata' ->> 'org_id')::uuid
);

Even if a ServerAction or API route completely omits a tenant check, Postgres blocks both reads and writes at the DB layer.

2. The 8 Hardening Test Vectors

To make sure this actually holds up under weird edge cases, I set up integration tests that run before deploys to simulate bad actors:

1. Cross-tenant UUID injection: Querying Org A data using an Org B JWT.
2. RBAC escalation: Calling Admin endpoints using a Member session token.
3. Stripe webhook idempotency: Replaying duplicate/out-f-order events.
4. API key rotation: Accessing tables with revoked/expired keys.
5. Corrupted payloads: Unsigned/malformed webhook headers.
6. Audit log append integrity: Veifying logs can't be overwritten.
7. Session expiration: Expired JWT rejection across dynamic routes.
8. Race conditions: High-concurrency team invite acceptances.