Authorization Testing

Authorization testing establishes what an authenticated principal is permitted to do, and whether the application enforces that on the server for every entry point rather than only in the interface that presents it. Authentication asks who the caller is; authorization asks what that caller may reach. The two fail independently, and an application with sound authentication can still hand a standard user another tenant's records.

What an attacker is trying to achieve

The attacker already holds a valid session — a self-registered account, a low-privileged role, or a former employee's credentials. The objective is to reach data or functions belonging to another principal or to a higher role, using requests the application accepts as well formed. Nothing here requires breaking a credential, which is why these flaws survive an authentication review that finds nothing wrong.

Test cases

4 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.

WEB-AUTHZ-01 Path Traversal and File Inclusion

Objective — Determine whether a parameter resolving to a file path or an included resource can be steered outside its intended directory, exposing files the application never meant to serve or executing a resource of the caller's choosing.

How it is tested — Enumerate every parameter that names a resource rather than carrying data — downloads, exports, report retrieval, template and language selection, and archive extraction. For each, submit relative traversal sequences, their URL- and double-encoded forms, absolute paths, and null- or extension-terminated variants, testing the read case and the include case separately. Where uploads exist, test whether an uploaded file can afterwards be named by one of these parameters.

Prerequisites — Each file-handling feature exercised once through normal use so the legitimate request shape is known; an intercepting proxy; a target file whose presence outside the web root can be confirmed independently.

Indicators — Content from outside the document root in a response body, an error disclosing an absolute filesystem path, a timing or length difference between an existing and a non-existent path, or behaviour changing when an included resource is redirected.

Coverage — WSTG-ATHZ-01V12.3.1V12.3.2CWE-22CWE-73

Depth — Hybrid Automated tooling finds the unencoded traversal in an obvious parameter. The encoded, nested and upload-then-include variants require manual work.

WEB-AUTHZ-02 Authorization Schema Bypass

Objective — Establish whether the access control decision is taken on the server for every entry point and every role, rather than expressed only in the navigation the interface renders.

How it is tested — Exercise the application once with each role, recording the full request history to produce a matrix of roles against functions. Replay every request captured under a privileged account using each lower-privileged session and with no session at all, changing only the credential. Extend the replay to entry points that do not render a page — API routes, export handlers, job triggers — which commonly miss the check the page controller applies. Request functions never linked for the role.

Prerequisites — One account per role including the least privileged; a proxy retaining request history; a statement of which roles are intended to reach which functions, so an unexpected success is distinguishable from an intended one.

Indicators — A privileged function completing under a lower-privileged or absent session; a 200 where 401 or 403 is expected; a redirect to a login page that nonetheless performed the state change.

Coverage — WSTG-ATHZ-02V4.1.1V4.1.5CWE-285CWE-862

Depth — Manual A scanner has no model of which role should reach which function, so it cannot tell an authorization failure from correct behaviour.

WEB-AUTHZ-03 Privilege Escalation

Objective — Determine whether a principal can acquire rights beyond those assigned — vertically, to a higher role, or horizontally, into another tenant or ownership scope — by way of the application's own state-changing functions.

How it is tested — Enumerate every mechanism that writes an authorization attribute: registration, profile updates, invitation and role assignment, group membership, password reset, support impersonation, and API token issuance. Attempt to set those attributes directly by adding fields the interface never sends — role, tenant and ownership identifiers submitted alongside legitimate ones — and to retain them after the granting condition is withdrawn. Confirm that a downgrade takes effect on the existing session rather than at next sign-in.

Prerequisites — Two accounts at different privilege levels; the ability to register or be invited; a proxy; and, where roles are administered by a separate console, access to observe the resulting state.

Indicators — A role, tenant or ownership attribute changing in response to a request that should not control it; privileges surviving revocation; a token that outlives its grant; an invitation flow letting the invitee choose the role.

Coverage — WSTG-ATHZ-03V4.1.2V4.1.3CWE-269

Depth — Manual Requires knowing which attribute governs privilege in this application, which is specific to its data model rather than to a signature.

WEB-AUTHZ-04 Insecure Direct Object References (IDOR)

Objective — Determine whether object identifiers accepted from the client are authorised against the requesting session, rather than merely validated for format and then trusted.

How it is tested — Enumerate every request carrying an object reference, wherever it travels — path segments, query parameters, JSON body fields, headers and cookies. With two accounts at the same privilege level, replay each request substituting the other account's identifier, repeating for sequential, UUID, hashed and encoded identifiers, including those appearing only in responses. Test writes as well as reads, since ownership is often checked on retrieval and not on update. Confirm the server's decision, not the interface's.

Prerequisites — Two accounts at the same privilege level in different ownership scopes; an intercepting proxy; and the object identifiers each account can see through ordinary use.

Indicators — A response returning another principal's data, or a state change applied to an object outside the session's ownership, with the request otherwise well formed and the status code indistinguishable from a legitimate one.

Coverage — WSTG-ATHZ-04V4.2.1CWE-639

Depth — Manual Not reliably detectable by automated scanning: the request is valid in every respect a scanner can inspect, and only knowledge of who owns the object separates success from failure.

What we need from you

One account for every role the application defines, including the lowest and, where self-registration exists, a freshly registered one; at least two accounts at the same privilege level in different tenants or ownership scopes; an intercepting proxy retaining full request history; and a description of which roles are intended to reach which functions. Where a role cannot be provisioned, that part of the matrix is reported as untested rather than assumed sound.

Standards this category maps to

Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.

WSTG-ATHZ-01 — Testing Directory Traversal File Include
V12.3.1 — Verify that user-submitted filename metadata is not used directly by system or framework filesystems and that a URL API is used to protect against path traversal.
V12.3.2 — Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files (LFI).
CWE-22 — Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
CWE-73 — External Control of File Name or Path
WSTG-ATHZ-02 — Testing for Bypassing Authorization Schema
V4.1.1 — Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed.
V4.1.5 — Verify that access controls fail securely including when an exception occurs.
CWE-285 — Improper Authorization
CWE-862 — Missing Authorization
WSTG-ATHZ-03 — Testing for Privilege Escalation
V4.1.2 — Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.
V4.1.3 — Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege.
CWE-269 — Improper Privilege Management
WSTG-ATHZ-04 — Testing for Insecure Direct Object References
V4.2.1 — Verify that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records.
CWE-639 — Authorization Bypass Through User-Controlled Key

Further reading: our research write-up on broken authorization.

Tell us what the system does and what worries you.

If a penetration test is not what you need yet, we will say so.

Book a scoping call See the test catalogue