API Authorization Testing

Why it matters

Authorization defects expose data and actions to people who already hold a valid account. The OWASP API Security Top 10 (2023) ranks Broken Object Level Authorization first (API1:2023): one missing ownership check lets any customer read other customers' addresses by changing a number in the URL.

Normal use never shows these defects: the app displays only the user's own data and hides admin buttons. Only a test that deliberately calls the API as the wrong user finds them.

Roles, ownership and the access policy

An authorization decision combines who the caller is, what they want to do and which object it touches. Most products combine role-based access control (RBAC), where a role such as customer, support agent or admin grants functions, with ownership rules: customers act only on their own objects. Multi-tenant products add one more: users never see another company's data.

Written down, these rules are the access policy, your test basis. The OWASP Authorization Cheat Sheet recommends denying by default, granting least privilege and validating permissions on every request. For testing this means:

• The API is the boundary, not the screen: hiding the "Refund" button protects nothing if POST /v1/orders/{id}/refund accepts a customer's token.
• The role comes from the server's own records or a verified token claim, never from client input such as an X-Role: admin header or "isAdmin": true in a body.
• Scopes, from the OAuth lesson, limit what the client application may do: a token without the required scope gets 403 with insufficient_scope. They add to the role and ownership checks and never replace them: a token with orders.write still may not change another customer's order.
• As in the API authentication lesson, 401 means no valid credential and 403 means a known caller is refused. RFC 9110 also allows 404 to hide that a resource exists; the contract says which one applies.

Try it: JWT Decoder

Three levels: function, object and property

Authorization breaks at three levels, each a risk in the OWASP API Security Top 10. Gaining a higher role's functions is vertical privilege escalation; reaching another user's data in the same role is horizontal.

• Function level (API5:2023, Broken Function Level Authorization): may this role call this operation at all? A customer calls GET /v1/admin/users, or switches GET to DELETE on a path they may only read.
• Object level (API1:2023, BOLA, also known by the older name IDOR, insecure direct object reference): may this user act on this object? Customer B sends the id of A's order. Ids hide in paths, query strings, bodies, headers and nested routes such as /orders/9021/invoice.
• Property level (API3:2023, Broken Object Property Level Authorization): may this user see or set this field? A response returns fields the caller must not see, or the API accepts a field the caller must not set, often called mass assignment.

# Function level: customer A's token on an admin function
GET /v1/admin/users
Authorization: Bearer <token of customer A>
-> expected 403

# Object level: customer B's token on customer A's order
GET /v1/orders/9021
Authorization: Bearer <token of customer B>
-> expected 404 (the contract hides other customers' orders)

# Property level: a customer sends a field only admins may set
PATCH /v1/users/me
Authorization: Bearer <token of customer A>
Content-Type: application/json

{"displayName": "Sara A.", "role": "admin"}
-> expected 400, or the role field ignored; A stays a customer

Try it: API Request Builder

Build the test matrix: users × requests

The matrix turns the policy into test cases you can count. Build it before sending anything:

• Rows: an anonymous caller, every role, and two users of the same role (A and B), because horizontal tests need objects that are not yours; in multi-tenant products, a user of another tenant too.
• Columns: every endpoint and method in the OpenAPI document, including admin, search and export endpoints and older versions still deployed.
• Cells: the expected result from the policy, on test objects with a known owner, written before execution. Most cells are refusals, and defects hide there.
• Execution: change only the token, then check the status, the body (no other user's data, no forbidden fields) and the state: a 403 that still saved the change is a defect.
• Lists: GET /v1/orders for B must not include A's orders, even with ?customerId= added.

Try it: OpenAPI → Test Cases Try it: API Response Comparator

Worked example: an orders API

A shop's orders API: customers read and change only their own orders; support agents read any order and issue refunds but change none; admins may do everything and alone manage users. Another customer's order returns 404. Order 9021 belongs to customer A. Of the matrix's 20 cells, only 8 allow the request.

Running it in the test environment, one actor's token at a time, found three defects:

• Customer B, R1: 200 with A's address instead of 404. Object level, critical: any customer can read any order.
• Customer A, R3: 201, a refund for A's own order. Function level, critical: owning an object does not grant every function on it, and here money leaves the shop.
• Support agent, R2: 403 as expected, but a fresh GET showed the new address. Function level, major: the status said refused, but the change was saved. Only the state check revealed it.

Orders API, test environment. Order 9021 belongs to customer A.

R1  GET    /v1/orders/9021          read the order
R2  PATCH  /v1/orders/9021          change the delivery address
R3  POST   /v1/orders/9021/refund   refund the order
R4  GET    /v1/admin/users          list all user accounts

Actor                  R1    R2    R3    R4
anonymous (no token)   401   401   401   401
customer A (owner)     200   200   403   403
customer B             404   404   404   403
support agent          200   403   201   403
admin                  200   200   201   200

Try it: REST API Tester Try it: API Authentication Tester

Frequently asked questions

References

• 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.
• 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.
• RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.
• OWASP Web Security Testing Guide (WSTG)OWASP FoundationThe reference methodology for testing web applications and APIs for security weaknesses, test by test.