Use row-level security so the database, not just the UI, decides which rows each authenticated user can read or change. That keeps access enforcement close to the data and reduces the risk of inconsistent checks across routes, APIs, and services.
Why database-layer enforcement is stronger than UI-only checks
Application access controls belong as close to the data as possible because the database is the last enforcement point before a row is returned or changed. If the UI or API is the only gate, any missed route, direct query path, background job, or internal service can bypass the intended restriction. That is why row-level security is so effective for multi-tenant and permissioned data sets.
At the database layer, the policy follows the data rather than the user interface. The same authenticated user can see one set of rows in one context and a different set in another, but the database enforces the rule consistently across applications, services, and ad hoc access paths. That reduces logic drift and makes access decisions easier to reason about.
- Use database-native row filters when access depends on tenant, owner, or role context.
- Keep application checks as a usability layer, not the only control.
- Design policies so the database can evaluate them without trusting every caller to behave correctly.
What row-level security changes in practice
Row-level security changes the trust boundary. Instead of asking each app endpoint to remember which records are safe to show or modify, the database evaluates policy at query time. That matters when the same table serves many routes, many services, or many business functions, because one missed condition no longer becomes a data exposure event.
This approach also helps when access rules are more granular than coarse table permissions. A user may be allowed to read only their own rows, rows from their department, or rows tied to a specific tenant. A database policy can encode that logic once and apply it uniformly, which is usually safer than duplicating the logic in controllers, resolvers, stored procedures, and jobs.
Teams should also decide how much of the rule belongs in application code versus the database. If the application still needs to compute attributes used by the policy, those attributes must be reliable and tamper-resistant. The database can enforce the final decision, but it cannot fix weak identity inputs or badly designed tenant context.
How to implement access rules without creating new bypass paths
Implementation usually works best when the database policy is simple, explicit, and based on stable claims such as authenticated user identity, tenant identifier, ownership, or role membership. Overly complex policy expressions become hard to test and easier to misunderstand, especially when multiple teams share the schema.
Database-layer enforcement should be paired with careful privilege design. The application should connect with a role that can only reach the intended schema objects, and the policy should be evaluated for every relevant read and write path. For teams using application access management practices, IAM and IGA Basics is a useful companion for understanding how entitlement design and access governance shape the claims that feed database policy.
For the data layer itself, hardening the database and verifying its configuration matters as much as the policy logic. MongoBleed breach is a reminder that exposed databases and weak configuration can make even well-intended access controls moot. Teams that rely on managed back ends should also review Firebase misconfiguration exposure 2024, which shows how missing security rules can turn data-layer access into broad exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Row-level security enforces authorization decisions at the data layer. |
| Recommendation — Enforce access checks at the data boundary, not only in the UI. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Database policies enforce who can read or modify rows. |
| AC-6 — Least Privilege | Database roles should restrict applications to only the rows and actions needed. | |
| Recommendation — Apply access enforcement in the database for every query path. Limit application and service roles to the minimum data access required. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Database-layer row restrictions are an access-control implementation choice. |
| Recommendation — Define and enforce access control rules at the data layer. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Row-level security is a prescriptive access-control safeguard for application data. |
| Recommendation — Implement and review granular data access rules for applications. | ||
Practitioner Guidance
What to verify: Test the policy through the database itself, not only through application endpoints. Confirm that direct queries, alternate services, exports, and background jobs all receive the same row restrictions.
What to prioritise: Start with the smallest set of attributes that express real business access, such as tenant, owner, or department. If you need many exceptions to make the policy work, the entitlement model is probably too loose.
Common mistake: Treating UI filtering as access control. UI logic improves experience, but only database enforcement prevents a forgotten code path from becoming a disclosure or unauthorized update.
Practitioner takeaway: The goal is not simply to hide rows in the interface, but to make the database the final and consistent decision point for who can read or change each record.
Related resources from NHI Mgmt Group
- How should teams implement a single SDK layer for multi-provider LLM access without rewriting application code?
- How should security teams choose between network-level access tools and application-layer zero trust controls?
- How should teams enforce authorization decisions at the data layer instead of scattering permission checks through application code?
- What do teams get wrong when they try to block private IP access with application-layer checks?