How to review authorization logic for broken access control and IDOR vulnerabilities

If you are reviewing a pull request or existing codebase, use the process below to detect broken access control in code. You will trace each sensitive action, verify object ownership and role checks, then test denial paths for IDOR and business-logic bypasses.

1. Map the authorization boundary

Before reading implementation details, list every endpoint, job, command, and service changed by the code. The deciding factor among dev-tools products is whether they support this exact workflow.

For each sensitive action, record:

• Who can call it?
• Which object does it access?
• Which tenant, account, or owner should control that object?
• What roles or states are required?
• Where is the decision enforced?

This is the first step in learning how to find IDOR vulnerabilities in a codebase. Search for user-controlled identifiers such as user_id, account_id, project_id, and order_id. Then follow them into database queries and service calls.

A risky pattern looks like:

invoice = Invoice.get(request.params["invoice_id"])
return invoice.download()

The identifier is valid, but there is no proof that the current user may access that invoice. A safer query scopes the object to the authenticated principal:

invoice = Invoice.find_by(
    id=request.params["invoice_id"],
    account_id=current_user.account_id
)

Use this broken access control review checklist while mapping the flow.

2. Review authorization logic in the pull request

When deciding how to review authorization logic in pull requests, inspect both the changed code and its callers. A check in a controller may not protect a background job or internal service called elsewhere.

Ask these questions:

• Is authentication confused with authorization?
• Is the role check performed before the data is returned or changed?
• Does the check use the requested object's owner or tenant?
• Can a user alter an identifier, HTTP method, or hidden field to bypass it?
• Are bulk actions authorized for every object, not just the first one?
• Are deleted, suspended, or archived records handled safely?

A useful authorization review checklist for pull requests should include negative cases. For example, a customer who can view their own order must receive a denial when requesting another customer's order, even if the order ID is guessed.

For broader automated coverage, teams can compare manual review with pull request scanner products. A tool should produce evidence that connects the input, authorization decision, and protected action.

3. Check for business-logic bypasses

Not every flaw is a missing if statement. Business logic vulnerability examples include:

• Applying a discount multiple times by replaying a request
• Approving your own expense through a direct status update
• Transferring more money than the available balance
• Inviting users to a project after losing membership
• Calling an administrative action through an alternate endpoint

Use an IDOR prevention checklist for developers:

• Enforce ownership or tenant scope in the data query.
• Authorize every object in batch requests.
• Reject state transitions that skip required steps.
• Prevent users from approving their own actions.
• Recheck permissions inside asynchronous jobs.
• Avoid trusting hidden fields such as role, owner_id, or status.

These are common IDOR vulnerability examples in web applications because the application accepts a valid object reference without validating whether the caller may use it.

4. Verify with tests and a rescan

Add access control testing examples to the pull request:

1. Authenticate as a permitted user and confirm success.
2. Authenticate as a different tenant or role and confirm denial.
3. Replace the object identifier with another valid identifier.
4. Try the same action through alternate methods or endpoints.
5. Test empty, duplicated, and mixed-ownership bulk requests.
6. Confirm denied requests do not leak object details.

Your broken access control code review checklist is complete only when both success and failure paths are covered. Run tests against real authorization boundaries, not just mocked permission helpers.