Your brief says staff can update jobs and customers can check progress. Then someone asks whether a staff member can export every customer's records, whether a customer can open another customer's attachment, or whether an administrator automatically gets to read everything.
Decide these boundaries before development. For each action, agree who may perform it, on which records, under which conditions, and what evidence will show the rule works. A list of job titles alone cannot answer those questions.
Start with five decisions:
- Which roles need each action: viewing, changing, exporting or managing access?
- Which customer account, organization, assignment and record state limit it?
- Which fields and attachments remain private even when a record is visible?
- When do changes to access take effect for sessions, downloads and exports?
- Which allowed and denied cases will the developer demonstrate?
Use the matrix and worksheet below to turn those decisions into a brief. The work-order business, roles and records are fictional planning examples. No application was implemented or security-tested for this article.
Authentication is not authorization
Authentication establishes an identity; authorization decides what that identity may do. Being signed in does not grant access to every record. OWASP distinguishes these controls and recommends defining access requirements during design.[1]
Replace 'staff access' with a full sentence: 'An active dispatcher may reassign an open work order within their own organization.' It identifies the person, action, resource and boundary.
Now ask whether that dispatcher needs the customer's billing attachment to schedule the work. If not, leave that permission out. OWASP recommends least privilege and denying access by default rather than treating unspecified access as allowed.[1]
Build a role-and-permission matrix
In this fictional application, an organization is a separate business using the system. Each has staff, customer accounts and work orders. Each customer account may have several named users. Every allowance below is limited to the user's current organization. 'No' means denied under this proposed policy, not under every possible business model.
| Role | View work orders | Change work orders | Export work orders | Manage users |
|---|---|---|---|---|
| Customer user | Own customer account's orders; customer-visible fields | Add comments to those orders; no status or price changes | No | No |
| Technician | Assigned orders; operational fields only | Work notes and permitted progress updates on assigned orders | No | No |
| Dispatcher | Organization's operational orders | Assignment and scheduling fields on open orders | No | No |
| Operations manager | Organization's operational orders | Dispatcher actions plus explicit completion or reopening | Approved operational columns for own organization | No |
| Account administrator | No access from this role alone | No | No | Invite, disable and assign approved roles within own organization |
The matrix deliberately separates account administration from operational access. If someone needs both, grant the second role deliberately. Agree how combined roles interact and whether explicit restrictions override allowances. Do not leave that to accidental implementation behavior.
Treat the final column as a separate permission decision too: which roles may an administrator grant, to whom, and who approves higher access? In this example, 'manage users' is not permission to grant arbitrary roles or cross organization boundaries.
List prices, sensitive attachments, internal notes and audit records as separate resources or field groups. 'Can view an order' is incomplete if its response also contains fields that role should never see.
Assignment, account membership, organization and record state matter alongside role names. OWASP describes attribute- and relationship-based controls for conditions that simple role checks cannot express well.[1] You do not need to choose a policy engine in the brief. You do need to state the conditions it must enforce.
Define customer-account and organization boundaries
For this example, agree the following policy choices:
- Creating an order gives no permanent personal ownership. Current assignment determines technician access.
- A customer user belongs to an approved customer account, not every account with a similar email domain.
- A role in Organization Cedar gives no rights in Organization Maple. A user belonging to both needs an authorized organization context for each action.
- Reassignment removes the old technician's access on subsequent requests unless another explicit rule grants it.
- Closed orders cannot be changed through ordinary scheduling; reopening is a separate manager action.
Your business may choose different rules. The value is exposing them before they become assumptions in code.
Do not accept 'the identifiers are hard to guess' as the boundary. OWASP's guidance on insecure direct object references, or IDOR, says complex identifiers do not replace object-level access checks. A user who obtains an unauthorized object's identifier must still be denied.[2]
Enforce permissions beyond the interface
Hiding an export button can improve the interface. It cannot be the control protecting the export. OWASP says client-side checks must not decide access; enforcement belongs server-side or at another trusted enforcement point, and permissions must be validated on every request.[1]
Ask your developer to identify enforcement points for pages, APIs, attachments, exports and administrative actions. Apply the policy wherever a record is reachable. OWASP includes static resources in access-control planning and requires checks for the specific object, not just its general type.[1]
For a background export, make another explicit decision: what happens if access is removed after the request but before generation or download? For this example, require generation within the approved organization and column scope and authorization again at download. Ask how the actual implementation handles revocation and already-generated files. This is a proposed requirement, not a verified capability of a named product.
Require allowed and denied acceptance cases
A successful allowed action is only half the demonstration. OWASP recommends authorization unit and integration tests, and its IDOR guidance describes multiple-account testing across authorization scopes.[1][2]
Use synthetic accounts and records in an authorized test environment. Do not probe another business's application or real customer accounts. These are proposed acceptance cases, not executed test results.
| Scenario | Expected result for the fictional policy | Evidence to request from your developer |
|---|---|---|
| Assigned technician opens their order | Allowed operational fields only | Actual response and field assertions for that build |
| Technician directly requests an unassigned order | Denied; protected data absent | Test request/response and unchanged-state check for attempted writes |
| Customer requests another account's known order ID in the same organization | Denied | Two synthetic customer accounts and object-level result |
| Cedar manager requests a known Maple order or export | Denied despite matching role names | Cross-organization read, update and export cases |
| Technician directly requests manager-only reopening | Denied; order remains closed | Server-side response and persisted state |
| Account administrator without an operational role requests an order | Denied | Separate administration and operational cases |
| Dispatcher sends a price change alongside a valid schedule edit | Unauthorized price change does not occur | Agreed reject-or-ignore behavior and persisted-record assertions |
| Disabled user's existing session requests an order or download | Denied within the agreed revocation window | Session/token conditions, timing and actual result |
Specify observable results, not just an HTTP status. A denied read must not return protected fields or attachments; a denied write must not change persisted state. Agree public error behavior that avoids unnecessary disclosure of sensitive record existence. OWASP discusses safe failure handling and sensitive information in error responses.[1][2]
Copy this acceptance-evidence worksheet
For each agreed case, ask the developer or tester to complete:
- Case and business rule: which matrix cell or boundary is being checked?
- Build and conditions: application build, relevant framework and authorization-component versions, configuration, and session/token state.
- Synthetic setup: user roles, organization, customer account, assignment and target record.
- Action: the request or operation, including a direct request where relevant.
- Expected result: allowed fields or denial, plus the permitted final record state.
- Actual result: response, field assertions and persisted-state checks, with evidence location.
- Accountability: tester, test date and unresolved differences.
A screenshot of a missing button does not prove the server denied a direct request. Keep evidence free of credentials, tokens and real customer records.
These cases can become regression checks, but passing them does not establish that an application has no security defects. OWASP says authorization unit and integration tests are not substitutes for dedicated security testing.[1]
Plan access changes: joining, moving and leaving
Finish the brief with three short conversations. These are planning recommendations, not claims about a particular compliance standard.
Joining: who verifies the person's organization and customer-account membership? What minimal role is granted first? Who approves more powerful access?
Moving: when someone changes team, assignment or organization, which old permissions disappear? Do temporary permissions expire? Who reviews accumulated access? OWASP recommends periodic permission review and watching for privilege creep.[1]
Leaving: who disables the account, what happens to active sessions and tokens, and what happens to pending exports? State the revocation window, then ask your developer to demonstrate it under the actual session and caching design. Do not assume removing a user from an administration screen revokes every existing access path.
Identify who reviews role changes and denied administrative actions. OWASP recommends appropriate logging while warning that excessive logging can unnecessarily expose sensitive information.[1] Request useful audit evidence without copying passwords, tokens or full sensitive records into logs.
Take a permission brief to your developer
Bring a first-pass matrix, sensitive-field and attachment inventory, customer-account and organization boundaries, access-change decisions, and allowed and denied cases. Mark uncertain rows 'decision needed' with a named business decision-maker instead of silently allowing broad access.
Ask a prospective developer: where is each rule enforced, how will we verify denial as well as success, and which checks run again when the application changes? Those answers are more useful than a general promise that an app will be secure.
If you are still defining the underlying workflow, start with the internal-tool planning guide. To frame a web-application discussion with CodeDrawn Digital, prepare a project brief covering the workflow, users and access boundaries. Use synthetic examples; do not include credentials or customer records. The site's helper lets a visitor request an email draft; it does not confirm app opening, sending or receipt. This checklist is a planning aid, not security certification or a promise of a particular service scope.
Sources
[1] https:
[2] https: