The question authorisation testing answers
Authentication establishes an identity. Authorisation then determines which action that identity may perform on a particular record. OWASP recommends checking these rules on every request and denying access by default when no appropriate permission exists.
For a software provider, the business questions are specific: can customer A edit only their own orders? May a read-only project role export files? Can support staff access only the customers assigned to them? A working sign-in process does not answer those questions. [2]
A small matrix makes expectations explicit
We recommend starting with the functions that matter most to the business. The planning matrix below is not a test result or a description of a real customer application. It illustrates how expected permissions can be recorded clearly before testing.
- List the permitted actions and data boundaries for each role.
- Record the owner or tenant of each test dataset.
- Treat reading, editing, deleting and exporting as separate actions.
- Include exceptional permissions, temporary grants and role changes.
| Test identity | Expected permitted access | Expected restriction |
|---|---|---|
| Customer A | Read their own approved documents | Documents belonging to customer B |
| Read-only project role | View assigned project information | Change or delete project information |
| Authorised support role | Support the customer area approved for the engagement | Customer areas outside that assignment |
Prepare suitable accounts and test data
The test environment needs distinguishable identities and records. For object access, OWASP describes several users with separately owned objects and, where relevant, different privileges as a useful basis.
Provide meaningful test data for the agreed workflows. Empty accounts, for example, offer little basis for examining document exports. Record which data belongs to which account and which functions are actually used in production. Share credentials only through the agreed secure channel.
Project owners should confirm expected permissions with the person responsible for the business process before testing starts. If the product and support teams disagree about what a role is meant to do, an unexpected result cannot be classified confidently as a defect. [1]
Assess workflows across the routes people use
A portal may provide the same information through its interface, an API and an export function. Include the relevant routes together in the scope. Hiding a menu item does not establish that the corresponding action is blocked on the server.
For IT providers serving several customers, we also recommend recording responsibility: who authorises the testing, who operates the application and who decides the business rules? Permission from one customer does not automatically cover other customers on a shared service. Make those test boundaries explicit.
Choose the right scope between an external check and a penetration test
Make results usable for the people fixing them
A useful finding connects the tested role, the action, the affected data boundary and the expected rule. The development team can then understand the observed difference without first reconstructing the entire permissions design.
For retesting, also identify the software version and permission relationship to be checked again. After a correction, the legitimate workflow still matters. Blocking every request may stop an unauthorised action while also making the required feature unusable.
Record combinations that were not tested separately. This keeps the result useful for release decisions and subsequent changes. The required depth follows the agreed application functions; an external configuration check alone cannot establish these permission relationships.
Turn findings into clear remediation and retesting decisions
Related reading
Sources & further reading
Primary sources checked on 05.10.2026.
Sources and limitations are identified in the article.