Turn customer, staff, and administrator roles into testable access rules for orders, attachments, exports, and permission changes, with a service-platform example.
A working login screen does not guarantee private customer accounts. A correctly authenticated customer may still reach someone else's order if the server checks only whether a session exists. After asking who the user is, the application must ask whether that person may perform this action on this record now. Product owners and developers should agree on the answer before permissions become scattered across buttons and pages.
Write a business policy, not just role names
Consider a hypothetical platform for commissioning design work. It has customers, project coordinators, billing staff, and managers. Customers read their own requests and upload relevant attachments. Coordinators follow assigned projects and share drafts. Billing staff access invoice information needed for their work but do not alter design files. Managers assign projects and change staff roles. These are proposed rules for this example, not universal rules for every company.
The business might decide coordinators need to know whether an invoice is paid without seeing its billing address. Record that distinction instead of giving every employee complete access. OWASP's authorization guidance recommends least privilege, denial by default, and checks on every request. Begin with narrowly explained permissions and add access when a business need is established.
Connect the user to the particular record
In this platform, PR-204 belongs to customer Salma in Company A. A customer role alone cannot authorize reading it: another customer, Samir, has the same role. Access must follow a trusted relationship between user and order. Apply that relationship to detail views, file downloads, messages, and PDF exports, not just the order listing.
OWASP's IDOR guidance explains why complicated identifiers cannot replace object-level access checks. Keep a convenient public reference such as PR-204 and a random internal identifier if useful; neither is a password. Scope lookups to authorized records and derive the user from trusted session context rather than a browser-supplied ownerId.
Make one access decision concrete
For a design-draft download, our example policy could require an active session, a file linked to an existing project, and a user who is either its customer or its currently assigned coordinator. The draft must also be marked shareable with that party. An internal work-in-progress is not automatically a client deliverable. If a relationship is missing, stop before returning file content rather than hiding already delivered data in the interface.
Review four cases with the business: the customer downloads the shared draft; another customer is denied; a coordinator removed from the assignment is denied; billing staff can read the invoice but not the draft. This short discussion exposes product disagreements early. If a customer needs to invite a colleague, define membership rather than suggesting password sharing or making every colleague the account owner.
Carry company boundaries beyond the page
A staff member might work with two organizations on the same platform. Choosing an organization in a menu does not create membership. Requests need a trusted organization context that also constrains data access. OWASP's multi-tenant guidance addresses isolation beyond page rendering, including caches and background work.
In the hypothetical platform, a weekly export job records the intended company rather than collecting every project and asking the browser to filter it. The resulting file needs an appropriate access policy. A cache entry must not hand Company A's report to Company B. Document these paths in the database design so relationships remain visible as features grow.
Protect fields as well as whole actions
Permission to edit an order title is not permission to change its owner or paid amount. Use explicit editable-field lists for each operation, as described in OWASP's mass-assignment guidance. Our customer may update a draft description, while payment confirmation belongs to a separate authorized workflow.
Keep session protection distinct from authorization. Review session management and CSRF protection for your architecture; neither substitutes for an object permission check. Decide how removing an employee affects existing sessions and sensitive queued work. Revocation needs observable behavior, not merely a changed label in administration.
Build a compact permission test matrix
Use accounts and data you control in an authorized test environment. Create two customers, two companies, an assigned employee, and an unassigned employee. For each sensitive action, test allowed and denied cases, then test again after access is revoked. Hiding a button is insufficient: exercise the server request and verify that it produces neither an unauthorized change nor a data leak.
- Read paths: details, search results, counts, attachments, and exports.
- Write paths: content updates, assignment, deletion, and approval transitions.
- Sharing: membership invitations, revocation, and temporary download links.
- Concurrency: an assignment changes during a protected operation.
- Failure: unavailable permission data must not become automatic approval.
Add these cases to your automated website tests. Record sensitive permission changes without copying private conversations or attachments into logs. Give someone responsibility for reviewing access when an employee leaves or a project changes scope, and include that review in your maintenance process.
Is one admin role enough? It can be appropriate for a very small team when its responsibilities and membership are deliberate. As support, billing, and editing diverge, separate needed actions instead of inventing many unclear role names. A useful permission system is one the business can explain and the server can consistently enforce. This checklist is a design starting point, not a substitute for a security assessment of the deployed application.
Prepared with AI assistance; technical references are included for verification.