Topic starter
12/06/2026 9:08 pm
TL;DR: Centralised authorization only solves part of the problem if applications still fetch broad datasets and filter later, because post-filtering creates over-fetching, pagination drift, and brief in-memory exposure, according to Cerbos. Pre-filtering pushes authorization conditions into the query plan, making data access more efficient and safer by design.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “Don't fetch that. A developer's guide to pre- vs. post-filtering for authorization”.
Key questions
Q: What breaks when authorization is done after data retrieval?
A: Post-fetch filtering wastes database and application resources, but the bigger issue is that it exposes data to the application before access is decided.
Q: Why does pre-filtering reduce exposure in access-controlled applications?
A: Because the database only returns records that already match the policy conditions, unauthorized data never needs to pass through application memory.
Q: When should teams use a hybrid pre-filter and verify pattern?
A: Use it when the application is high-security or mission-critical and a final policy check is worth the extra overhead.
Practitioner guidance
- Shift row-level enforcement into the query plan Translate policy output into database-native filters so unauthorized rows are excluded before the application receives them.
- Reserve post-filtering for validation, not primary enforcement Use a second authorization check only as a final safety net for mission-critical paths, not as the main method for deciding which records to fetch.
- Test pagination against authorized subsets Verify that page size, offsets, and result stability still behave correctly when authorization constraints are applied first.
Bottom line: Post-filtering can leave applications handling data they should never have received, even when the final response is correct.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
12/06/2026 11:00 pm
Pre-filtering changes authorization from a cleanup control into a prevention control. Post-filtering assumes it is acceptable for unauthorized data to enter application memory briefly, then be removed before delivery. That assumption is too weak for modern access-controlled systems, especially where row-level entitlements are large, dynamic, or sensitive. The practitioner implication is that retrieval architecture and authorization design have to be treated as one control surface, not two separate steps.
A question worth separating out:
Q: How do access-control teams decide whether filtering belongs in the app or the query layer?
A: If the policy can be translated into row-level conditions, the query layer should enforce it first. The app should not fetch broad datasets only to discard most of them later, because that shifts the control point too late and creates avoidable exposure and scaling problems.
👉 Read our full editorial: Pre-filtering authorization data at the source beats post-filtering