CtrlK
BlogDocsLog inGet started
Tessl Logo

g14wxz/tenant-isolation-rls

Enforces absolute data boundaries between tenants in shared schema via RLS policies on tenant_id.

100

Quality

100%

Does it follow best practices?

Impact

Pending

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Overview
Quality
Evals
Security
Files

Tenant Isolation RLS

Enforces absolute data boundaries between tenants in a shared-schema architecture using Postgres Row Level Security policies keyed on tenant_id.

Overview

This tile creates four RLS policies (SELECT, INSERT, UPDATE, DELETE) on a target table. Each policy extracts the tenant_id claim from the caller's JWT via auth.jwt() -> 'app_metadata' ->> 'tenant_id' and matches it against the row's tenant_id column. No row is ever visible or writable across tenant boundaries.

Reference

JWT Claim Extraction

auth.jwt() -> 'app_metadata' ->> 'tenant_id'

This expression is embedded in every policy's USING and WITH CHECK clause.

Required Table Structure

ColumnTypeConstraint
tenant_iduuidNOT NULL

Verification Query

SELECT policyname, cmd, qual, with_check
FROM pg_policies
WHERE tablename = '<table>';

RLS Enable Check

SELECT relrowsecurity FROM pg_class WHERE relname = '<table>';

Dependencies

  • supabase-mcp-verification -- validates migration output and policy state.
  • custom-access-token-hook -- injects tenant_id into JWT app_metadata. Without this hook, all policy checks fail with NULL comparison.

Composition Position

  • MUST execute after custom-access-token-hook is deployed.
  • MUST execute before any application-layer queries that assume tenant isolation.
  • Incompatible with schema-per-tenant architectures -- those isolate at the schema level and MUST NOT use this tile.
Workspace
g14wxz
Visibility
Public
Created
Last updated
Publish Source
CLI
Badge
g14wxz/tenant-isolation-rls badge