Security Guides

Broken access control: can one user reach another user’s data?

Estimated Reading Time =

2 minutes

Technical Level =

Advanced

Threat Level =

High

Attack Type =

Vulnerability Exploit

Editorial illustration for broken Access Control and IDOR

What you will learn

What you will learn

Being signed in should not give a person access to every record. The server must check permission for the specific object and action on every request.

Being signed in does not mean a person should see every record in an application. Access control is the set of rules that decides what each user can read or change. A failure in those rules can expose another customer’s invoice, another employee’s file, or an administrator-only action.

Understand the idea

The application must check the requested record as well as the user’s identity. Hiding a button is not enough because a request can reach the server by another route. A long or hard-to-guess record number may reduce accidental discovery, but it does not replace a permission check.

A simple way to follow the process
  1. Identity

    The service knows who made the request.

  2. Permission

    It checks access to this record and this action.

  3. Boundary

    A different user’s record stays inaccessible.

A practical example

Suppose a donor portal lets one user download their receipt. In an approved test, the team uses a second account and asks whether it can access the first account’s receipt. The expected result is a refusal, even when the second account knows the receipt’s identifier.

What to do next

  1. Scope object queries to the caller's permissions. Check tenant membership, ownership, role, and relevant business state on the server.
  2. Default to denial. A missing policy or failed lookup should not become permission. Handle failures without leaking another customer's details.
  3. Control writable fields. Do not accept client-provided ownership, tenant, or privilege fields merely because they appeared in a valid request.
  4. Test alternate routes. Include mobile APIs, background jobs, file storage links, support tooling, and bulk actions.

How to check the result

Keep a small table of user roles, records, and allowed actions. Test both the actions that should work and those that should be refused after a change.

The record ID is difficult to guess. Is that enough?

No. Unpredictable identifiers can reduce guessing, but they do not replace server-side authorization. Test with accounts that have different access rights in an approved environment.

Sources and useful guides

The following resources provide background and more detailed guidance. Use the sections that match your service and situation.

Scroll to Top