Multi-tenant isolation at MeritSKU is not enforced by software WHERE clauses in ORM queries; it is enforced directly at the database kernel level using PostgreSQL 16 Row-Level Security (RLS). Cross-tenant queries are physically impossible.
1. PostgreSQL RLS Session Context
Before executing any tenant query, the connection pool sets the local session variable app.current_workspace_id to the authenticated tenant UUID.
Every table in the database includes an RLS policy that automatically filters rows to match current_setting("app.current_workspace_id"). If a developer writes SELECT * FROM products, only the authenticated tenant’s products are returned.
CREATE POLICY tenant_isolation_policy ON products
FOR ALL
USING (workspace_id = current_setting('app.current_workspace_id', true)::uuid);2. The Stealth 404 Security Invariant
If a user attempts to request an entity belonging to another workspace, the API returns a generic HTTP 404 Not Found rather than HTTP 403 Forbidden.
This "Stealth 404" invariant prevents ID enumeration attacks by revealing zero information about whether an unauthorized entity exists.
3. 56/56 Multi-Tenant Penetration Suite
Our CI pipeline executes 56 automated penetration test vectors attempting cross-tenant injection, session tampering, and direct SQL bypass. 100% of attempts are neutralized.
Was this guide helpful?
Your feedback trains our editorial documentation standards.