How to Test APIs for Authorization Issues (IDOR)

You probably already test authentication. But how do you test whether a user is actually authorized to access a resource?

When testing an API, we usually verify that a user can log in, receive a token, and successfully call an endpoint. But authentication only answers who are you? Authorization answers a different question: what are you allowed to access or do? That second question is where a common API security vulnerability appears: IDOR (Insecure Direct Object Reference).

Why API authorization testing matters

Authorization failures are one of the most important API security risks. In the OWASP API Security Top 10 (2023), Broken Object Level Authorization (BOLA) is ranked #1. OWASP describes BOLA as a vulnerability where an API fails to properly verify whether the authenticated user is allowed to access the specific object referenced in a request.

The impact can be serious. Depending on the API, an authorization flaw could allow a user to:

• View another customer's personal information
• Access another user's orders or invoices
• Modify someone else's account
• Change another user's data
• Delete resources belonging to another user

A simple example of an authorization issue

Imagine an e-commerce application with this API. User A is authenticated and owns order 1001:

GET /api/orders/1001
Authorization: Bearer <user-A-token>

The API correctly returns:

{
  "id": 1001,
  "customer": "User A",
  "amount": 2500
}

Now User A changes the order ID. Order 1002 belongs to User B:

GET /api/orders/1002
Authorization: Bearer <user-A-token>

If the API returns User B's order:

{
  "id": 1002,
  "customer": "User B",
  "amount": 4800
}

How do you test authorization?

The basic idea is simple: use one user's credentials and try to access another user's resource.

1. 1

   Create two test users

   User A → userId: 101, User B → userId: 102.

2. 2

   Authenticate as User A, request User A's own resource

   GET /api/users/101 with a token for User A — this should succeed.

3. 3

   Change the object ID to User B's

   GET /api/users/102, still authenticated as User A. The API should prevent this — a 403 Forbidden is appropriate; some applications intentionally return 404 Not Found to avoid revealing the resource exists.

What should you test?

Don't look only for IDs in URLs. Object references can appear in path parameters, query parameters, and request bodies — and the same authorization check should apply regardless of where the identifier comes from.

GET /api/orders/1002

Don't test only GET requests

A common mistake is testing whether another user's data can be read, but forgetting to test whether it can be modified or deleted. GET /api/orders/1002 should be tested — but so should:

• PUT /api/orders/1002
• PATCH /api/orders/1002
• DELETE /api/orders/1002

What about different user roles?

Authorization testing should also cover different roles — for example, Customer, Support Agent, Manager, and Administrator. A customer might be allowed to view their own orders and update their own profile, but not view another customer's orders, delete another customer's account, or access administrative APIs. A support agent may have broader access, while an administrator may reach resources other roles cannot.

IDOR vs. BOLA: are they the same?

You'll often see IDOR and BOLA used together. They're closely related, but not exactly interchangeable.

• IDOR (Insecure Direct Object Reference) describes a common attack pattern where an application exposes an object reference and fails to verify whether the requester is authorized to access that object.
• BOLA (Broken Object Level Authorization) is the broader API security category used by OWASP.

1. 1

   User A sends GET /orders/1002

   The request includes an object reference — the order ID — directly in the path.

2. 2

   API trusts "1002"

   The API treats the ID as valid without further checks.

3. 3

   Doesn't verify ownership

   No check confirms the order actually belongs to User A.

4. 4

   User B's order is returned

   Result: BOLA / IDOR.

If you're searching for ways to test this vulnerability, you'll encounter all of these terms — they point to the same underlying issue:

How can you automate authorization testing?

Testing a few endpoints manually is straightforward. The challenge starts when an application has hundreds of APIs — for example, 300 endpoints, 50 resources, 5 user roles, and multiple environments adds up to thousands of test combinations. Manually changing IDs and switching between users quickly becomes difficult to maintain.

1. 1

   Authenticate User A

   Obtain a valid token for the first test user.

2. 2

   Identify User B's resource

   Locate an object ID owned by a different user.

3. 3

   Send User B's resource ID, using User A's token

   Execute the request as User A against User B's object.

4. 4

   Verify access is denied

   Expect 403/404 — anything else is a failed check.

User A + User B resource
  -> 403 / 404
  -> PASS

This type of test can become part of regular API regression and security testing, rather than something performed manually before a release.

API authorization testing checklist

Before considering your API authorization coverage complete, ask:

• Can User A access User B's resources?
• Can a user change an object ID to access another object?
• Are path parameters protected?
• Are query parameters protected?
• Are object IDs in request bodies validated?
• Can a user modify another user's resource?
• Can a user delete another user's resource?
• Are nested resources protected?
• Are different user roles properly restricted?
• Are authorization tests included in regression testing?
• Are authorization checks applied consistently across endpoints?

The key question to add to your API testing strategy

Authentication testing asks: *can this user log in and access the API?* Authorization testing goes one step further: *now that this user has access to the API, what exactly are they allowed to access and modify?*