Row-Level Security

Large amounts of data are usually stored in a database. You can picture this like a huge table: each column a characteristic, each row an individual entry. In a table of sick notes, each row therefore represents a person with their case. Row-Level Security means: the database decides, for every single row, who is allowed to see it. An employee queries the entire table and still only gets back their own row. The filter rule doesn’t live in the program making the query, but directly with the data.

Why a forgotten filter turns into a data leak

Without this technique, every program has to remember on its own to filter the data. An HR department app would therefore have to add to every query: only rows with my employee number. That works as long as nobody makes a mistake. In practice, though, many programs access the same database: the web app, the mobile app, an analysis tool, a script for the monthly report. If a single one of these forgets the filter, suddenly all the records are exposed.

This is exactly how many of the data breaches you read about come to be. Often the database itself hasn’t been hacked. More frequently, an interface simply returned more than it should have. Anyone who changed a single character in the web address suddenly saw someone else’s orders or invoices. Row-Level Security closes this gap at a central point.

A second reason is legal in nature. The General Data Protection Regulation requires that personal data only be accessible to authorized individuals. A rule that is anchored in the database itself can be checked and documented. That is considerably more convincing than the assurance that all programs have already been written correctly.

Rules that stick to the row

Technically, what you set up for a table is called a policy. This is a condition that can be true or false for each row. One example: the employee-number column must match the number of the logged-in user. On every query, the database attaches this condition invisibly. The user asks for all rows and receives only the matching ones.

What matters here is that the database knows who is asking. Depending on the system, there are dedicated user accounts for this, or an attribute sent along with the request, such as a user ID from the login process. Naturally, the user must not be able to forge this ID themselves. Otherwise they could simply claim to be someone else.

The rules can also be more complicated. A manager sees all rows of their department, executive management sees everything. This can be expressed within the same policy. However, Row-Level Security should not be confused with table-level permissions. There, you only decide whether someone is allowed to touch a table at all. Row-Level Security operates one level finer, namely within the table.

From SaaS platforms to the AI chatbot at the office

You’ll find this technique in practically every piece of software that serves many customers through the same system. An online accounting service stores the data of hundreds of companies in the same tables. A row-level rule ensures that Company A never sees Company B’s figures. Databases like PostgreSQL, SQL Server, or platforms like Supabase and Snowflake offer ready-made functions for this.

In tech news, the term currently comes up mainly in connection with AI. Many companies are building assistants that answer questions about internal documents and databases. Such an assistant must not read a salary list out loud to an intern. Since the language model itself cannot provide reliable access control, the restriction has to sit in the data source. Row-Level Security is one of the common tools for this.

A common misconception is that this technique replaces all other protective measures. It only protects against queries made through the regular database connection. Anyone who gets their hands on a backup copy of the entire database can read everything in it. Encryption, access control, and logging therefore remain necessary.