Access Control Testing

Why it matters

OWASP Top 10:2025 ranks Broken Access Control first (A01); the OWASP API Security Top 10 (2023) opens with Broken Object Level Authorization (API1) and also lists Broken Function Level Authorization (API5). Real users follow the screens built for their role, so testing that follows those screens never sends the requests that expose these defects, and one changed identifier can expose every customer's data.

For a tester these tests are cheap and valuable: two test accounts and a request tool, expected results fixed by the policy so they automate well, and findings that are often rated critical or major because they expose data or actions that belong to someone else.

Vertical, horizontal and function-level failures

Authorization answers one question per request: may this identity perform this action on this resource? The check has two levels. A function-level check asks whether this role may call this function at all (invite a user, export all invoices); an object-level check asks whether this user may act on this particular record (invoice 3107, not 3108). Two failures are named by the direction in which the caller gains access; the third by the check that is missing.

• Vertical privilege escalation: a lower role uses a higher role's function, for example a viewer sends the owner's POST /api/users. The check is missing or trusts the client, such as a role carried in a cookie or request body. Expected: 403, and nothing happens.
• Horizontal privilege escalation: the same role, someone else's record. An accountant of Company A changes one number and requests GET /api/invoices/3108, an invoice of Company B. OWASP calls this an insecure direct object reference (IDOR); the API Security Top 10 calls the defect Broken Object Level Authorization (BOLA). Expected: 403, or 404 when the contract hides other customers' records.
• Missing function-level access control: a function protected only by obscurity. The link is not shown, the endpoint is undocumented, the old /api/v1/export still answers, or the check covers GET but not DELETE on the same URL. Expected: 401 or 403 as the policy says; any success is a defect. A missing function-level check is also the usual cause of vertical escalation; the separate name keeps your attention on functions that no screen shows and no list names.
• A finer level: a user who may update a record changes a field that is not theirs, such as "role": "owner" in a profile update, which the API Security Top 10 calls Broken Object Property Level Authorization (API3:2023). Keep it on your list; the API security testing lesson goes deeper.

Try it: API Request Builder

From the access policy to a roles × actions matrix

The test basis is the access policy. Few teams write it down, so assemble it from the requirements, the role descriptions, each role's menus and the API contract, and have the product owner confirm it: every cell you cannot fill is a question. Rows are the roles, plus Anonymous and, for the horizontal case, a user of the same role in another team or company. Columns are every action the product offers, taken from every source rather than one role's screens: menus, the API contract, exports, admin pages, and the requests the highest role's session makes.

Fill every cell with the expected result before you send anything: success status and visible effect for an allowed cell, status and "no side effect" for a refused one. Each cell is a test condition: a refused cell whose action belongs to a higher role is a vertical test; an allowed cell that names a record is repeated with another user's record as the horizontal test; every column is also requested directly in every row as the function-level test. The OWASP Authorization Cheat Sheet asks teams to write unit and integration tests for their authorization logic; the matrix is the shared source for those tests and for yours.

Try it: OpenAPI → Test Cases

Worked example: an invoicing app with three roles

An invoicing service at https://invoices.test, in a test environment you have written permission to test, serves many companies. Policy: "A user belongs to one company and sees only its data; a request about another company's invoice returns 404. Viewers read invoices. Accountants also create and send invoices. Owners also export all invoices and invite users. Without a valid session the API returns 401." Test accounts: Maha (viewer), Yousef (accountant) and Rana (owner) in Company A, which owns invoice 3107, and Tariq (accountant) in Company B.

Sign in as Rana, perform each of the five actions once and copy every request it sends from the Network panel as cURL; opening invoice 3107, for example, also loads its PDF preview from GET /api/invoices/3107/pdf. Replay every request in a request tool with Maha's, Yousef's and Tariq's session cookie in turn and once with no cookie, changing nothing else. If a request also carries a token tied to Rana's session, such as an anti-CSRF token, swap it as well, or a refusal may come from that token check rather than from authorization. The run found two defects.

• Maha's replay of POST /api/invoices/3107/send returned 200 and the customer received the invoice: a vertical escalation; the check existed in the menu only. Severity: critical.
• Tariq's GET /api/invoices/3107 correctly returned 404, but the PDF preview request GET /api/invoices/3107/pdf returned the PDF: a horizontal escalation through a second route to the same record. Severity: critical.
• Every other cell matched the matrix. Confirm each fix by re-running the whole column, not only the failed cell.

Expected result per cell, written from the policy before any request is sent

Caller                 A1 view 3107  A2 create  A3 send 3107  A4 export  A5 invite
Anonymous              401           401        401           401        401
Maha, viewer A         200           403        403           403        403
Yousef, accountant A   200           201        200           403        403
Rana, owner A          200           201        200           200        201
Tariq, accountant B    404           -          404           403        403

401 = authentication (no session)    403 = vertical: a function above the role
404 = horizontal: Company B's user on Company A's invoice (the contract hides it)

Try it: cURL Parser Try it: API Authentication Tester Try it: API Response Comparator

Where unprotected functions and identifiers hide

A matrix is only as complete as its columns, and function-level defects live in the columns nobody listed. Before you sign off, look for what the obvious list misses.

• Other routes to the same record: a PDF or print view, a search endpoint with a company filter, a bulk export, a sharing link.
• Other methods and versions of the same URL: a check on GET but not on PUT or DELETE, or an old API version still deployed.
• Values the client sends about itself: companyId, role or isOwner in a body, query string, cookie or hidden field. The server must take identity and company from the session; change these values and expect them to be ignored or refused.
• Files and random identifiers: an uploaded PDF served from a storage URL without a session check, or a UUID that is hard to guess. Both hide a record; neither authorises the reader. Copy a real identifier from the other test account and expect a refusal.

Try it: REST API Tester

Frequently asked questions

References

• OWASP Web Security Testing Guide (WSTG)OWASP FoundationThe reference methodology for testing web applications and APIs for security weaknesses, test by test.
• OWASP Top 10:2025OWASP Foundation · 2025The ten most critical web application security risks, with how to test for and prevent each.
• OWASP Cheat Sheet Series: AuthorizationOWASP FoundationAccess control done right: least privilege, deny by default, check permissions on every request, prefer attribute- or relationship-based models, and test the authorization logic.
• OWASP API Security Top 10 (2023)OWASP Foundation · 2023The ten most common API weaknesses: broken object-level authorization, broken authentication, unrestricted resource consumption and more.