Broken access control
An application allows an action or resource access that its policy should deny.
The idea
Broken access control occurs when permissions are not correctly enforced. Examples include accessing another user’s record, performing administrative actions without the appropriate role, or bypassing an intended workflow. Enforce authorization on trusted systems for each relevant resource and action, deny by default where appropriate, and test negative cases. Permissions should be understandable and aligned with business rules.
In practice
An authorized lab test changes a record reference and checks that the server refuses access to a record owned by another test account.
A common misunderstanding
A hidden URL or unpredictable identifier is not a complete authorization control.
Check your understanding
What test matters alongside a successful authorized request?
Think it through: A request from an identity that should be denied, including direct API access.
Write the permission rule before testing
A fictional grants portal has applicants, reviewers, and finance staff. An applicant can edit a draft, a reviewer can score an assigned application, and finance can release an approved award. There is no single 'logged in' check that expresses these relationships. Each operation needs a rule covering the actor, the record, the action, and the current workflow state.
Horizontal access failures cross between peers, such as one applicant reading another's file. Vertical failures cross privilege levels, such as an applicant invoking an approval action. Workflow failures can occur even within a permitted role when the application allows an award to be released before approval. These distinctions help reviewers choose meaningful negative cases.
Do not assume a front-end control expresses a server guarantee. A disabled button is useful guidance, but a caller can still send the underlying request. The same is true of a mobile app that never displays an administrative feature. Permission enforcement must cover the operation wherever it is reachable.
Turn rules into a compact matrix
For the grants example, list create, view, edit, approve, and release operations. Add sample records belonging to different applicants and records in draft, reviewed, and approved states. For each combination, state the expected outcome before testing. This avoids deciding that a surprising response is acceptable merely because the application produced it.
Use only designated test identities and dummy documents. If an unexpected disclosure occurs, preserve enough evidence to identify the failure without downloading unrelated records. Fixing one controller is insufficient when the same data is reachable through search, export, or background jobs. A durable repair centralizes the policy where appropriate while keeping the business rules visible and testable.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
OWASP: Web Security Testing Guide