Knowledge · Architecture

    What Is Row Level Security?

    Row Level Security moves the access decision into the database, so a forgotten filter in application code returns nothing instead of everything.

    What is Row Level Security?

    Row Level Security is a database feature that attaches access rules to a table itself, so every query is automatically filtered by who is asking. Instead of trusting application code to add the right condition, the database refuses to return rows the requester is not entitled to see.

    Key takeaways

    • Row Level Security puts the access decision next to the data.
    • It is a backstop for application code, not a replacement for it.
    • A table with policies but no grants is still unreachable — both are required.
    • Enabled with no policies means deny everything, which is the correct default.
    • Policies need coverage per operation: read, insert, update and delete each need one.

    Why application filtering alone is fragile

    Application code has to remember. Every new query, every new report, every new background job is another opportunity to omit the tenant condition, and the omission does not look like an error — it looks like a page that works and shows more than it should. Row Level Security removes the dependence on memory: the condition is a property of the table, not of the query.

    The four-part shape of a correctly secured table

    • Create the table with an explicit tenancy column.
    • Grant the specific privileges the intended roles need, and nothing more.
    • Enable row-level security, which by itself denies everything.
    • Write one policy per operation the application legitimately performs.

    Coverage is the thing that actually rots

    Policies are written when a table is created and then forgotten. A new operation is added later, a policy is dropped during a migration, or an operation is covered for one role but not another. The gap is invisible until someone hits it, which is why coverage deserves to be checked mechanically rather than reviewed occasionally.

    Where URBLD fits

    URBLD's secure development policy requires every new table in the public schema to ship with explicit grants, row-level security enabled and policies written in the same migration; a table without them is treated as an incomplete change. Tenant tables evaluate organization membership through security-definer helper functions, and an internal coverage check enumerates expected table, role and operation combinations and reports the ones with no matching policy.

    FAQ

    Frequently Asked Questions

    Straight answers about how URBLD runs the business end-to-end.

    More in Architecture

    How information should move through a business.

    Browse Architecture
    Share this page