How changing IDs, URLs and request parameters can reveal missing authorisation checks.
After looking at authentication bypass and username enumeration, the next topic felt like a natural step.
Authentication answers one question:
<pre><code>Who are you?
</code></pre>
Access control answers another one:
<pre><code>Are you allowed to access this?
</code></pre>
That second question is where Broken Access Control and IDOR issues usually appear.
From a developer’s point of view, it is easy to think that once the user is logged in, the application is mostly safe. But being authenticated does not automatically mean the user should be able to access every object, record, page or API response.
This is where the real security logic starts.
<h2>Authentication vs Authorization</h2>
<img src="https://media.daily.dev/image/upload/s--kDEvYeve--/f_auto/v1779196366/ugc/content_1ad5ec7e-64be-42eb-9b1a-5f17f08202cf?_a=BAMAMiWQ0" alt="c886f902-d053-4053-a1dc-a260f06007ce.png">
Authentication confirms the identity of the user.
Authorisation checks what that user is allowed to do.
For example:
<pre><code>Authentication:
User A is logged in.

Authorization:
Can User A access invoice 123?
Can User A edit profile 456?
Can User A download this file?
Can User A view this API response?
</code></pre>
A user can be fully authenticated and still not authorised to access a specific resource.
That distinction is very important.
Many access control issues happen because the application checks that the user is logged in, but does not check whether the requested object actually belongs to that user.
<h2>What Broken Access Control Means</h2>
Broken Access Control happens when an application does not properly enforce permissions.
This can include many different problems:
<ul>
<li>viewing another user’s data,</li>
<li>editing another user’s profile,</li>
<li>accessing admin functions as a normal user,</li>
<li>changing object IDs in URLs or requests,</li>
<li>reusing another user’s request with a different session,</li>
<li>accessing restricted API endpoints directly,</li>
<li>relying too much on frontend visibility or hidden UI elements.</li>
</ul>
In simple terms, the application allows a user to do something they should not be allowed to do.
<h2>What IDOR Looks Like in Practice</h2>
IDOR stands for Insecure Direct Object Reference.
The idea is quite simple.
The application exposes a reference to an object, such as an ID, filename, user ID, order ID or document ID. The user changes that value and the server returns data that belongs to someone else.
For example:
<pre><code>GET /account?id=1001
</code></pre>
If changing it to:
<pre><code>GET /account?id=1002
</code></pre>
returns another user’s account data, the problem is not the ID itself.
The real problem is that the backend trusted the supplied ID without checking whether the logged-in user was allowed to access that object.
That is the key lesson for me:
<pre><code>IDOR is not just about changing numbers.
It is about missing authorization checks.
</code></pre>
<h2>What I Practised in the Labs</h2>
In the labs, I focused on understanding how access control fails in real requests.
The most useful practical approach was working with two separate users.
Instead of testing only from one account, it is much more useful to compare behaviour between two users in Burp Suite.
My testing flow looked like this:
<pre><code>1. Log in as User A.
2. Access a resource or perform an action.
3. Capture the request in Burp.
4. Log in as User B.
5. Repeat the same action.
6. Compare the requests and responses.
</code></pre>
Then I could ask better questions:
<pre><code>What happens if User A tries to access User B&#x27;s resource ID?
What happens if I change an ID in the URL?
What happens if I change an ID in the request body?
What happens if I reuse another user&#x27;s request with my own session cookie?
Does the server check ownership?
Does the response change?
Do I get data that should belong to another user?
</code></pre>
This made the topic much clearer.
The best test is often not complicated. It is about creating two normal users and checking whether the backend correctly separates their data and permissions.
<h2>The Signals I Learned to Look For</h2>
<img src="https://media.daily.dev/image/upload/s--YSlsRsnb--/f_auto/v1779196349/ugc/content_0327aea9-de6f-47e9-9cd6-ffcf7c91b61c?_a=BAMAMiWQ0" alt="d93e4436-2651-4fc0-8c20-beb3905239b3.png">
During testing, I started paying attention to values that could control access to an object.
For example:
<pre><code>URL parameters
Path parameters
Request body values
JSON fields
Cookies
Headers
Hidden form fields
File names
User IDs
Order IDs
Document IDs
Account IDs
</code></pre>
The important question is not only:
<pre><code>Can I change this value?
</code></pre>
The better question is:
<pre><code>If I change this value, does the server still verify that I am allowed to access the result?
</code></pre>
A secure application should not trust the client to decide ownership or permissions.
The client can send an ID, but the server must verify it.
<h2>What This Taught Me as a Frontend Engineer</h2>
This topic connects strongly with frontend development.
As frontend developers, we often work with routes, IDs, API calls, user objects, conditional rendering and UI permissions.
We might hide a button, disable a link or only show certain UI elements for specific users. That is useful for user experience, but it is not real security by itself.
The real protection must happen on the server.
The frontend can help make the interface clearer, but it cannot be the final authority on access control. Anything sent from the browser can potentially be changed, replayed or modified.
This includes:
<pre><code>IDs in URLs
IDs in API requests
hidden fields
query parameters
JSON body values
client-side state
localStorage/sessionStorage values
cookies sent by the browser
</code></pre>
From an AppSec perspective, I need to stop asking only:
<pre><code>Does the UI allow this?
</code></pre>
and start asking:
<pre><code>Does the backend enforce this?
</code></pre>
That is a different mindset.
<h2>Developer Remediation</h2>
<img src="https://media.daily.dev/image/upload/s--d-yVqxIp--/f_auto/v1779196327/ugc/content_b136d91e-be79-468c-a281-960952e9e60e?_a=BAMAMiWQ0" alt="38c9a76f-6b29-49be-81c5-6ce414a91dfa.png">
The main fix for IDOR and Broken Access Control is proper server-side authorisation.
The backend should verify access every time a user requests or modifies a resource.
Good practices include:
<pre><code>Check ownership on the server
Use session identity instead of trusting user-supplied IDs
Apply authorisation checks consistently
Use indirect references where appropriate
Avoid exposing predictable object IDs when possible
Deny access by default
Log suspicious access attempts
Test with multiple user roles and accounts
Add automated tests for authorisation boundaries
</code></pre>
For example, if a user requests an order, the backend should not only check:
<pre><code>Is this user logged in?
</code></pre>
It should check:
<pre><code>Does this order belong to this user?
Is this user allowed to view it?
Is this user allowed to edit it?
</code></pre>
That check needs to happen on every sensitive endpoint, not only on the page route.
<h2>Main Takeaways</h2>
The biggest takeaway from this topic is that access control must be enforced by the server, not assumed from the UI.
Changing an ID should not be enough to access another user’s data.
A user being logged in is not enough. The application must also check what that user is allowed to access.
The second takeaway is that testing access control is often very practical.
Creating two users, comparing their requests in Burp Suite and swapping IDs, cookies, or parameters can reveal a lot about how the application actually enforces permissions.
The third takeaway is that IDOR is simple to understand, but serious in impact.
In a real application, it could expose personal data, invoices, documents, messages, account details or internal records. In some cases, it could also allow unauthorised changes, not only unauthorised viewing.
For me, this topic made authorisation feel much more concrete.
It is not just a theoretical security concept.
It is a question the application must answer correctly on every sensitive request:
<pre><code>Is this user allowed to access this specific thing?
</code></pre>
<h2>GitHub Notes</h2>
I am keeping my AppSec learning notes and lab summaries here:
<a href="https://github.com/cieslikprzemyslaw/cybersecurity/tree/master/eng/key-web-vulnerabilities/02-broken-access-control-idor" target="_blank" rel="noopener nofollow">Broken Access Control and IDOR notes on GitHub</a>
<h2></h2>
#appsec #websecurity #brokenaccesscontrol #idor #burpsuite #frontend

Przemyslaw

Broken Access Control and IDOR (Insecure Direct Object Reference) are explained from a developer's perspective, emphasizing the critical distinction between authentication (who are you?) and authorization (are you allowed to access this?). IDOR occurs when a backend trusts client-supplied IDs without verifying ownership, allowing users to access other users' data by simply changing an ID in a URL or request. A practical two-user testing methodology using Burp Suite is outlined, covering URL parameters, request body values, cookies, and headers as potential attack vectors. Key remediation practices include server-side ownership checks on every sensitive endpoint, using session identity instead of trusting user-supplied IDs, and denying access by default. Frontend developers are specifically reminded that hiding UI elements is not a security control — real protection must be enforced on the server.

Key Web Vulnerabilities #2: Broken Access Control and IDOR