A regional manager may need a shared dashboard but only their own region's records. Hiding a filter or menu option does not enforce that boundary. The same authority must apply when the user drills into a chart, downloads an export or opens a saved report link.
Related service: CRM, ERP and web application development- 01Define the user's permitted records.
- 02Resolve identity from a trusted session.
- 03Enforce access during queries and jobs.
- 04Scope caches and downloads appropriately.
- 05Test revocation and cross-account attempts.
SECTION 01
Write the rule in business terms first
Describe who can see which records and why: assigned accounts, active team membership or a defined reporting role. Include shared ownership and temporary cover where needed. Separate permission to view a summary from permission to inspect detailed records or create an export. Avoid granting broad access simply to make a scheduled job easier to implement.
OWASP recommends server-side authorization checks. PostgreSQL row security can restrict records, but its documentation notes that privileged roles and table owners can bypass policies in particular circumstances. That is why testing only an administrator's successful query proves little about the intended user boundary. The chosen implementation needs explicit role-aware tests.
SECTION 02
Illustrative example: a manager changes regions
Imagine a manager moves from one region to another. The dashboard updates their visible records, but a queued export was created under the earlier membership. Decide whether the job and download require current authorization, and make that rule explicit. A stale download link should not silently become a permanent route to former access.
A shared cache also needs an appropriate permission boundary. If two managers request the same chart dates, the system must not return the first person's private result to the second. This hypothetical example shows how access can fail outside the visible query filter even when the main screen looks correct.
SECTION 03
Include denied access in acceptance evidence
Ask the agency to demonstrate two ordinary accounts with different scopes. Try direct record URLs, altered request parameters, exports and saved report links. Verify what happens after a membership change or account removal. Tests should confirm denied behavior without exposing another user's private record details in the error message.
Document which service accounts can read broader data and how their use is constrained and audited. Review aggregate outputs that might reveal sensitive small groups even without row details. Begin with a clear, manageable permission model; adding many exceptions increases review and testing work. The handoff should include the access matrix and repeatable tests, not just a list of roles in an admin screen.
SECTION 04
Frequently asked questions
Is filtering by region in the browser enough?
No. A client can alter requests. The server must derive and enforce the permitted scope from trusted identity and access records.
Do exports need separate access tests?
Yes. Background generation, stored files and download links can follow different code paths from the dashboard.
Why test with non-admin accounts?
Privileged accounts may bypass restrictions that should apply to normal users. Acceptance needs representative allowed and denied cases.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Row security policiesPostgreSQL
- Authorization implementation guidanceOWASP Foundation
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy