Explain OWASP broken access control and how you'd test for IDOR

Broken access control is a failure to enforce, on the server, what an authenticated user is allowed to do. Authentication answers “who are you?”; authorization answers “are you allowed to do this to this resource?”. Most access control bugs are authorization bugs: the user is genuinely logged in, but the server trusts something the client sent.

Forms it takes

• Horizontal escalation: a user accesses another user’s data at the same privilege level. IDOR is the typical example.
• Vertical escalation: a normal user performs admin actions, for example calling DELETE /api/admin/users/42 because the button was only hidden in the UI.
• Forced browsing: reaching pages or endpoints that are not linked but not protected either.
• Mass assignment: sending extra fields like "role": "admin" or "ownerId": 7 in an update body and the server persisting them.
• Token and claim tampering: editing a JWT claim or a cookie value and the server accepting it without proper signature or authorization checks.

What IDOR is

An Insecure Direct Object Reference happens when an endpoint uses a client-supplied identifier (/orders/1043, ?accountId=88, a file name) to fetch an object and does not check that the object belongs to the caller. Sequential integer IDs make it trivial to exploit, but UUIDs do not fix it: they only make IDs harder to guess, and they still leak through URLs, logs and shared links. The fix is an ownership or permission check on every request.

How I test for it

1. Create at least two users in the same role (A and B) and, where relevant, users in different roles and tenants.
2. As user A, create resources and record their IDs.
3. As user B, call every read, update and delete endpoint with A’s IDs. Do this for path parameters, query parameters, body fields and headers.
4. Repeat with no token, an expired token and a lower-privileged role.
5. Assert the right outcome: 403 Forbidden, or 404 Not Found if the API deliberately hides existence. Then verify that A’s resource is unchanged and that the error body leaks nothing.
6. Check list and search endpoints too: filters like ?userId= are a common leak.

Write operations matter most. A read IDOR leaks data; an update or delete IDOR lets an attacker modify other customers’ accounts.

Automating it

Manual probing finds the first bug; automation stops regressions. I keep an access matrix of endpoint, role and expected status, and run it as a parameterized API test:

@ParameterizedTest
@CsvSource({
    "GET,    /api/orders/{id}, USER_B, 404",
    "PUT,    /api/orders/{id}, USER_B, 404",
    "DELETE, /api/orders/{id}, USER_B, 404",
    "GET,    /api/orders/{id}, ADMIN,  200"
})
void orderAccessIsEnforced(String method, String path, String caller, int expected) {
    String orderId = createOrderAs(Users.USER_A);
    given()
        .auth().oauth2(tokenFor(Users.valueOf(caller)))
        .contentType("application/json")
        .body("{}")
    .when()
        .request(method, path, orderId)
    .then()
        .statusCode(expected);
}

Every new endpoint gets rows in the matrix as part of its definition of done. Tools like Burp Suite (with extensions such as Autorize) help during exploratory work by replaying a high-privilege session’s requests with a low-privilege token.

What interviewers look for

• A clear split between authentication and authorization, and the point that hiding UI elements is not access control.
• A concrete two-user method, covering writes and deletes, not just reads.
• Verification that state did not change, not only that a 403 came back.
• A plan to keep these checks running in regression.

Common mistakes

• Thinking UUIDs prevent IDOR.
• Only testing GET endpoints.
• Accepting a 200 with an empty body without checking whether the update actually happened.