What is row-level security (RLS)?
A database feature that limits which rows a query can return, based on who is running it, enforced by the database itself.
RLS — Row-level security (RLS) is a database feature that attaches access policies to individual rows. A query returns only the rows the current user is allowed to see, enforced by the database rather than the application. It protects data even when application code is wrong.
Also known as: row-level security
Why it matters
Most application security relies on the application's own code to decide what a user may see. It filters results before they reach the screen. Row-level security moves that decision down into the database itself. A policy attached to a table says which rows a given user may read or write. The database enforces it on every query, whatever the application code asked for. If the application has a bug that forgets to filter a query, RLS still blocks rows the user should not see. The enforcement does not depend on the application getting it right.
The detail that trips teams up is how several policies on the same table combine. In common implementations, policies combine with OR logic by default. A row is visible if it satisfies any one applicable policy, not only if it satisfies all of them. A single overly permissive policy, perhaps written for an internal tool or a debugging convenience, can quietly defeat every other restrictive policy on the same table. It exposes rows those other policies were meant to protect. Review how the policies on a table combine, not only whether each one looks correct on its own. That is what catches this before it becomes a real exposure.
How RLS is applied
- 1
Enable RLS on a table
The table is switched from unrestricted access to policy-gated access.
- 2
Define access policies
Rules are written specifying which rows a given user or role may see or modify.
- 3
A query runs against the table
Any query, from the application or a direct connection, is subject to the policies.
- 4
The database filters rows
Only rows matching an applicable policy are returned or modified.
- 5
Policies are reviewed for how they combine
Multiple policies on one table are checked together, not only individually.
The mistake to watch for
Questions
- How is RLS different from role-based access control?
- Role-based access control typically governs what actions a role can perform at the application or feature level. RLS governs which specific rows in a database table a query returns. It is enforced at the database layer, whatever the application intended.
- Does RLS protect against bugs in application code?
- Yes. That is one of its main advantages. The database enforces the policy rather than relying on the application to filter correctly. A bug in application code that forgets a filter still cannot expose rows the RLS policy blocks.
- Why is it dangerous to add a permissive RLS policy?
- Policies on the same table are commonly combined with OR logic. One policy that allows broad access, even added for a narrow internal purpose, can override every stricter policy also applied to that table.