Row-Level Security (RLS)
Row-level security allows policies to control which rows a role may read or modify. Enable RLS on a table and create policies that define conditions for commands and roles. RLS can provide a valuable defense-in-depth layer for multi-tenant applications, but the application must establish tenant context safely and understand policy behavior.
Table owners typically bypass row-level security unless configured otherwise, and roles with BYPASSRLS can bypass it. Test policies using the same role and connection settings as the application. RLS does not replace authentication, authorization design, or secure handling of tenant identifiers.
Enable a tenant policy
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_documents
ON documents
USING (tenant_id = current_setting('app.tenant_id', true)::bigint)
WITH CHECK (tenant_id = current_setting('app.tenant_id', true)::bigint);💡 This is an illustrative policy pattern. The application must set the tenant context safely for each transaction or connection, handle missing settings, and ensure untrusted clients cannot choose another tenant's context. Validate casts and policy behavior in a test environment.
Key Takeaways
- RLS policies filter rows according to role and policy conditions.
- Table owners and BYPASSRLS roles need special consideration.
- Test policies using the actual application role and tenant context.
Knowledge Check
What does row-level security primarily control?