Broken Access Control usually happens because the application checks the wrong thing, in the wrong place, or trusts data it should not trust.
In Part 1, I started before the exploit.
I looked at response consistency, error messages, timing, privileged account naming, password policy, and small signals that can tell us whether an application is worth investigating further.
In Part 2, I want to move closer to the real access control failure.
But I do not want to reduce A01 to only one pattern:
<pre><code>Change the ID and access someone else’s data.
</code></pre>
That is important, but Broken Access Control is wider than IDOR.
The core idea:
<pre><code>Broken Access Control happens when the application makes an authorization decision too early, too broadly, or based on data it should not trust.
</code></pre>
<h2>Mistake 1: treating authentication as authorization</h2>
<img src="https://media.daily.dev/image/upload/s--O88-hQOf--/f_auto/v1783499350/ugc/content_aae46322-8990-445a-bb28-4291cc00ffec?_a=BAMAMicg0" alt="d018b600-131c-4627-8e58-031f58b05201.png">
Authentication answers:
<pre><code>Who are you?
</code></pre>
Authorization answers:
<pre><code>Are you allowed to do this?
</code></pre>
A valid session, cookie, or token proves that the application recognised a user. It does not prove that this user can access a specific object, perform a specific action, or operate inside a specific tenant, company, team, or organisation.
A common mistake is protecting an endpoint with only a login check:
<pre><code>isAuthenticated ✅
isAllowed(user, action, resource) ❌
</code></pre>
<h3>What this means</h3>
The endpoint may be unavailable to anonymous users, but still available to any logged-in user.
A normal user is not anonymous, but they are still not automatically an administrator, owner, manager, approver, or member of every organisation.
<h3>How to protect against it</h3>
Every sensitive request should answer four questions:
<ul>
<li>Who is the user?</li>
<li>What resource are they trying to access?</li>
<li>What action are they trying to perform?</li>
<li>Are they allowed to do that?</li>
</ul>
The check should not stop at “valid session”.
<h2>Mistake 2: trusting request parameters</h2>
Another common mistake is allowing request data to define the access context.
<pre><code>{
 &quot;userId&quot;: &quot;user_123&quot;,
 &quot;companyId&quot;: &quot;company_456&quot;,
 &quot;role&quot;: &quot;admin&quot;,
 &quot;ownerId&quot;: &quot;user_123&quot;,
 &quot;approved&quot;: true
}
</code></pre>
Some of these fields may be legitimate business data in the right context.
The problem starts when the backend treats them as trusted proof of permission.
<h3>What this means</h3>
If the user can control <code>userId</code>, <code>companyId</code>, <code>role</code>, <code>ownerId</code>, <code>isAdmin</code>, <code>approved</code>, or similar fields, they can try to move themselves into a different access context.
The request is not a trusted source of identity or permission.
The request is input.
And input can be modified.
This is risky when backend logic uses request values directly:
<pre><code>if request.companyId == target.companyId:
 allow
</code></pre>
That looks like a check, but it may still be based on attacker-controlled data.
<h3>How to protect against it</h3>
The authenticated user should come from the server-side session or validated token context, not from the request body.
<pre><code>Do not ask the request who the user is.
Derive the user from the authenticated context.
</code></pre>
Then use server-side data to decide access.
Request parameters can identify what the user wants to access.
They should not prove that the user is allowed to access it.
<h2>Mistake 3: protecting the resource, but not the action</h2>
<img src="https://media.daily.dev/image/upload/s--4LYKDVve--/f_auto/v1783499420/ugc/content_3774895b-af34-4fac-a2b6-e6f944196778?_a=BAMAMicg0" alt="1fbb9076-d85b-4d06-9284-fa54c8d98dce.png">
In backend frameworks, we define routes, handlers, controllers, and HTTP methods.
The problem is not that <code>GET</code>, <code>POST</code>, <code>PATCH</code>, or <code>DELETE</code> magically exist without code.
The problem is that each handler may represent a different action, and each action needs its own authorization decision.
<pre><code>GET /api/reports/rpt_123 -&gt; can view?
PATCH /api/reports/rpt_123 -&gt; can edit?
DELETE /api/reports/rpt_123 -&gt; can delete?
POST /api/reports/rpt_123/export -&gt; can export?
</code></pre>
This may be the same resource, but it is not the same permission.
<h3>What this means</h3>
A user may be allowed to view a report, but not edit it.
A user may be allowed to edit a record, but not delete it.
A user may be allowed to see data in the application, but not export it.
If the application checks only “can access this resource”, the permission may become too broad.
<h3>How to protect against it</h3>
Use action-specific authorization:
<pre><code>can(user, &quot;view&quot;, report)
can(user, &quot;edit&quot;, report)
can(user, &quot;delete&quot;, report)
can(user, &quot;export&quot;, report)
</code></pre>
Defining a route is not the same as protecting the action behind that route.
Each handler needs an authorization decision based on the user, resource, scope, and action.
<h2>Mistake 4: exposing internal references without enforcing permission</h2>
This is more interesting than simply saying “do not hide buttons in the frontend”.
Imagine a user can access a dashboard. The dashboard contains references to pages or actions that should only be available to a more privileged user.
<pre><code>/admin/users
/admin/users/123
/admin/users/123/actions
POST /admin/users/123/delete
POST /admin/users/123/change-role
</code></pre>
The link or reference itself is not always the full vulnerability.
But it gives structure.
It tells the tester where to look next.
<h3>What this means</h3>
If the referenced page or action is still reachable without the required permission, the application has a real access control problem.
The issue is not only that the application revealed a link.
The issue is that the revealed page or action is still accessible.
This connects with Part 1.
Small signals and references can become a map. In Part 2, we follow that map and check whether authorization is actually enforced.
<h3>How to protect against it</h3>
The backend must enforce permission on every referenced page and action.
A dashboard can guide legitimate users, but it should not become the access control layer.
A useful rule:
<pre><code>Visible reference ≠ permission
Known URL ≠ permission
Reachable route ≠ permission
</code></pre>
Access control should not depend on whether the user discovered the route through the intended UI.
<h2>Practical review questions</h2>
When reviewing an endpoint or action, I would ask:
<ul>
<li>Is this endpoint only checking authentication?</li>
<li>Is the user identity taken from trusted context or from request input?</li>
<li>Does the request contain fields like <code>userId</code>, <code>role</code>, <code>companyId</code>, <code>ownerId</code>, or <code>isAdmin</code>?</li>
<li>Is the application checking the specific action, not only the resource?</li>
<li>Are <code>view</code>, <code>edit</code>, <code>delete</code>, <code>export</code>, <code>approve</code>, and <code>assign</code> treated as different permissions?</li>
<li>Does a dashboard, API response, or client-side file reveal sensitive routes?</li>
<li>If a sensitive route is known, does the backend still enforce permission?</li>
<li>Would the same request fail for a different user, role, tenant, or scope?</li>
</ul>
That last question is important.
Access control is not proven only by testing the user who is allowed.
It is also proven by testing users who should be denied.
<h2>Summary</h2>
Broken Access Control is not only about changing an ID in a URL.
It also happens when the application:
<ul>
<li>treats login as permission,</li>
<li>trusts request parameters,</li>
<li>protects the resource but not the action,</li>
<li>exposes internal references without enforcing permission.</li>
</ul>
A valid session, visible link, known URL, or request parameter is not proof of access.
The authorization decision belongs at the point of action.
<h2>My takeaway</h2>
The vulnerable request matters.
But the real question is why the request was trusted.
Was the check too broad?
Was it based on user-controlled data?
Was the action protected separately?
Was the route reachable only because nobody enforced permission behind it?
That is where Broken Access Control actually happens.
In Part 3, I want to go deeper into final requests, workflows, privilege escalation, and state-changing actions.
<h2>Extended version</h2>
This daily.dev post is a shorter technical version of the topic.
I wrote a longer Medium article where I go deeper into workflow checks, final requests, role/ownership/scope problems, and negative testing.
Read the expanded version here:
<a href="https://medium.com/@cprzemek91/owasp-top-10-2025-a01-where-broken-access-control-fails-in-real-applications-f3c28b500f21" target="_blank" rel="noopener nofollow">OWASP Top 10 2025 A01: Where Broken Access Control Fails in Real Applications</a>
<h2></h2>

Przemyslaw

Part 2 of a series on OWASP Top 10 2025 A01 (Broken Access Control) examines four common patterns where access control fails in real applications: treating authentication as authorization, trusting request parameters for identity or permission, protecting resources but not specific actions, and exposing internal references without enforcing backend permissions. Each mistake is explained with concrete examples and practical mitigation guidance. A checklist of review questions is provided to help developers and security testers audit endpoints systematically.

OWASP Top 10 2025 A01, Part 2: Where Broken Access Control Actually Happens