Authentication establishes who a user is. Authorization determines what that user may do. A successful login therefore does not prove that an application protects every record or administrative action. An authorization test matrix makes the expected permissions explicit so a tester can compare them with observed behaviour in an authorized environment.
This guide uses a fictional local training portal containing synthetic student submissions. It is a defensive learning exercise with supplied accounts, not a method for exploring someone else’s records. The goal is to test a small set of agreed permissions, record both allowed and denied cases, and give developers enough context to reproduce any discrepancy.
Define the policy before the tests
Ask the application owner to explain the intended rules. In the fictional portal, students may read and update their own draft submissions. They may not read another student’s work. An instructor may read submissions assigned to their class but cannot manage unrelated classes. An administrator has separately defined management permissions.
Write down exceptions such as shared records, published examples, or delegated access. A test cannot prove a violation until the expected rule is known. Where policy is unclear, record an open question. Do not turn a personal assumption about how the application should behave into a confirmed security finding.
Model actor, resource, and action
The actor is the account or role making the request. The resource is the record or feature being accessed. The action might be read, create, update, approve, export, or delete. These three dimensions provide a simple structure for a matrix, as described in OWASP’s authorization regression testing guidance.
For the lab, identify Student A, Student B, and Instructor C. Create Submission A owned by Student A and Submission B owned by Student B. Record these identities before testing. A matrix based only on roles can miss ownership restrictions between two people who share the same role.
Include positive and negative cases
Positive cases confirm that legitimate access still works. Student A should be able to view their own draft. Negative cases confirm that prohibited access is denied, such as Student A viewing Student B’s private submission. Both matter: a repair that blocks everyone may remove the symptom while breaking the application.
Include a signed-out case where relevant. Also consider transitions such as logout, role changes, or a record moving from draft to published. Keep these within the agreed scope and synthetic data. State changes can alter permissions, so test descriptions should include the resource state rather than only its identifier.
Distinguish horizontal and vertical boundaries
A horizontal boundary separates peers, such as two student accounts. A vertical boundary separates different privilege levels, such as a student and an instructor. Test these deliberately instead of assuming that passing one proves the other. An application may protect administrative screens while failing to check ownership on ordinary records.
Use a small, representative set of permitted test records. There is no need to enumerate unrelated identifiers to demonstrate a lab policy failure. Working with supplied synthetic objects keeps the evidence precise and avoids exposing information outside the exercise. Record which boundary each case is designed to examine.
Inspect server behaviour, not only the interface
Hiding a button is useful interface behaviour, but it does not by itself establish authorization. The server must enforce the rule when the relevant request reaches it. Within the authorized lab, compare the expected result with the actual response and resulting state. A disabled control should not be the only basis for declaring the case passed.
Check more than the response code. An application might display an error while still changing a record, or return an apparently successful response containing no protected information. Record the response and inspect the agreed synthetic record afterward. Explain what was actually observed rather than assigning a finding from one status number alone.
Keep sessions separate
Use separate browser profiles or clearly controlled sessions for each test account. Accidentally sending a request with the instructor’s session can make an ordinary student action appear allowed. Record the account role in the evidence and confirm it before each important test. Session confusion is a common source of false conclusions.
Do not store live session tokens in the public matrix. Use a local evidence reference if raw request details are necessary. Sanitise cookies, authorization headers, and other secrets before sharing. The report should explain identity and permissions without providing a reusable credential to anyone who reads it.
Design a small matrix
A useful initial matrix contains Student A reading Submission A, Student A reading Submission B, Student B updating Submission B, Student B updating Submission A, Instructor C reading an assigned submission, and a signed-out visitor reading a private submission. Add expected allowed or denied outcomes to every row before execution.
For each row, record the environment, account, resource state, action, expected result, actual result, evidence reference, and conclusion. Use blocked or not tested when prerequisites are unavailable. A missing account or failed login is not a passed authorization check, because the intended request was never evaluated.
Report a discrepancy clearly
Suppose Student A can view the synthetic text of Submission B despite the private-owner policy. The report should identify the violated rule, the supplied test accounts, the minimum reproduction steps, and the observed synthetic content. State the plausible business impact while distinguishing it from actions that were not attempted.
Avoid claiming full database exposure from one permitted record unless evidence supports that scope. The developer needs a precise finding with a reasoned impact statement. Include a recommended design direction, such as consistent server-side ownership checks, without pretending to know the exact code change before reviewing the implementation.
Retest the policy after a repair
Repeat the original failed case on the repaired version, then check related positive and negative cases. If Student A is blocked from Submission B, also confirm that Student A can still access Submission A. Check the relevant role and ownership boundaries rather than only the original visible symptom.
Keep the old and new evidence references. Mark the outcome fixed, partially fixed, not fixed, or not retested, with a short explanation. A changed error message is not enough if protected data remains available through another tested path. Conversely, a network failure cannot demonstrate a successful authorization repair.
Turn the exercise into regression coverage
Once the policy is stable, the development team can encode selected cases as repeatable tests. Use dedicated data and predictable cleanup so the tests do not depend on a shared account’s accidental state. New roles and resources should trigger a matrix review. The permission model is a living part of the application design.
The matrix also helps during feature discussions. Before a new export or approval function is implemented, the team can ask which actors may use it and on whose records. This makes authorization an explicit requirement instead of a security check added only after the interface is finished.
Frequently asked questions
Does a hidden administrative menu prove access is blocked?
No. It demonstrates an interface restriction. Server-side enforcement must also be checked in the authorized environment using the intended account and action.
Should every denied request return the same status?
The exact response depends on the application’s design. The essential outcome is that prohibited information or actions are not provided. Document the expected response contract with the owner.
Is one successful negative test enough?
It covers that case only. Roles, ownership, resource states, and actions can have different rules. Use representative coverage and state the limits of the assessment.