A construction management system may hold commercially sensitive records for several organisations. Tenant isolation restricts access to those records. Chantier Manager uses PostgreSQL row-level policies alongside application access controls.

Policies and roles

PostgreSQL applies row-level policies to covered operations on tables where row security is enabled. Superusers and roles with BYPASSRLS bypass these policies. Table owners normally bypass them too, unless FORCE ROW LEVEL SECURITY is enabled. Policies must therefore be evaluated together with the application role and its privileges.

-- Illustrative example / Exemple illustratif
ALTER TABLE work_package ENABLE ROW LEVEL SECURITY;
ALTER TABLE work_package FORCE ROW LEVEL SECURITY;

CREATE POLICY work_package_tenant ON work_package
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

Illustrative policy, not an excerpt from the product. Role privileges and tenant-context handling must also be reviewed.

Startup validation

Chantier Manager’s production startup guard rejects an application database role with superuser or BYPASSRLS privileges. This checks a specific deployment condition. It does not, by itself, prove that every table policy or application permission is correct.

Testing different boundaries

Cross-tenant tests need at least two tenant contexts to check that one organisation cannot read or change another’s records. Policy tests inspect whether the expected tables have row security and the required policies. Single-tenant tests address operation in a dedicated deployment; they do not establish the cross-tenant boundary.