Access Control Belongs in the Database, Not the UI
Hiding buttons in the UI is not true security. Learn how Postgres Row-Level Security (RLS) enforces robust data access control at the database level.
Stock photo for illustration only, not from the actual event
- Hiding UI buttons does not constitute a real access-control mechanism.
- Postgres Row-Level Security (RLS) enforces permissions at the database layer.
- Append-only audit trails prevent historical records from being modified.
- Data security should be an inherent property of data, not application code.
The most common access-control bug isn't exotic: an application hides a button, and the developer considers the job done. However, the data remains just one crafted request away from exposure. If authorization lives exclusively in the user interface, it does not truly exist.
The solution is to push access control down to where the data actually resides—the database—using Postgres row-level security (RLS). This approach has been successfully implemented in a campus platform called Cendekia, an ISP operations portal, and a mining workforce application, each managing multiple distinct roles that must strictly view only their designated data.
Stock photo for illustration only, not from the actual event
With RLS enabled, a table will never return rows that a user is unauthorized to see, even if an explicit query asks for them. Because the policy is bound directly to the table, it holds true regardless of which screen, endpoint, or ad-hoc query initiates the request. Students view only their own grades, lecturers see their assigned classes, and administrators access the registry—with the rules enforced entirely by Postgres rather than relying on developers remembering to add a WHERE clause in every code handler.
Implementing Postgres Row-Level Security (RLS) embodies the Defense in Depth principle, mitigating the risk of human error where developers might forget to include filtering conditions in newly created API endpoints. Centralizing security policies at the database layer ensures complete coverage.
This represents a crucial architectural shift: authorization becomes a core property of the data itself rather than a habit of application code. New endpoints inherit these security boundaries automatically, ensuring that a forgotten filter can never cause a data leak because the database itself will refuse the operation.
Beyond regulating read and write operations, ensuring data integrity means preventing historical records from being quietly altered later. For attendance tracking and approvals within the mining application, the audit trail is strictly append-only at the database level utilizing Postgres triggers that reject any UPDATE and DELETE commands on those tables. The application is permitted to append new facts, but it cannot rewrite history. When payroll calculations or operational disputes rely on these logs, a simple assurance that nobody tampered with them is insufficient—the database guarantees it.
Hiding a control element is purely a matter of user experience (UX), whereas enforcing access at the database level is true security. By prioritizing database-level rules, properly indexing tables, and backing them with immutable records, the security guarantees remain intact regardless of front-end behavior.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment