Breaking Access Control: How a Simple ID Change Exposed Sensitive Data

Introduction

It didn't start as a complex exploit.

No advanced payloads. No sophisticated tooling.

Just a simple request… and a small change.

GET /api/user/profile?userId=123

At first, everything looked normal. The application returned the logged-in user's profile data.

But what happens if you change the ID?

That one question uncovered a critical vulnerability.

The Moment of Discovery

While testing the application, I intercepted the request using Burp Suite.

The request contained a parameter:

userId=123

Naturally, the next step was to modify it.

GET /api/user/profile?userId=124

The response came back.

Not an error. Not a denial.

But another user's data.

That's when it clicked — IDOR.

What Just Happened?

This is a classic case of Insecure Direct Object Reference (IDOR).

The application exposed internal object identifiers (userId) and failed to verify whether the requesting user had permission to access that data.

In simple terms:

If changing an ID gives you access to someone else's data, access control is broken.

Going Beyond Curiosity

At this point, it wasn't just about viewing another profile.

What else could be accessed?

Further testing revealed similar patterns:

  • /api/orders?userId=124
  • /api/documents?ownerId=124
  • /api/settings?userId=124

Each endpoint responded with unauthorized data.

This wasn't an isolated issue.

It was a systemic access control failure.

Horizontal vs Vertical Impact

The vulnerability unfolded in two ways:

Horizontal IDOR

Accessing data of other users at the same privilege level.

Viewing profiles, orders, and personal data of other users.

Vertical IDOR

Attempting access to higher privilege resources.

What if an admin ID exists?

GET /api/user/profile?userId=1

If this returns admin data — the impact escalates dramatically.

Why This Happens

At its core, the issue is simple:

The application trusted user input.

It assumed:

  • The userId belongs to the logged-in user
  • The client will not tamper with requests

But in security:

Never trust the client.

Without proper authorization checks, the backend blindly returned data based on input.

Real Impact

This isn't just a minor flaw.

IDOR vulnerabilities can lead to:

  • Exposure of Personally Identifiable Information (PII)
  • Unauthorized data access across accounts
  • Account takeover scenarios
  • Financial data leakage
  • Privilege escalation

In many cases, this aligns with high-risk issues highlighted by OWASP under Broken Access Control.

How to Identify IDOR (Practical Approach)

If you're testing an application, here's a simple methodology:

1. Find Endpoints with Identifiers

Look for:

  • userId
  • accountId
  • orderId

2. Intercept Requests

Use tools like Burp Suite.

3. Modify the Identifier

Try:

  • Sequential values
  • Other known IDs
  • UUIDs

4. Analyze the Response

  • Does it return another user's data?
  • Does it allow unauthorized actions?

If yes → vulnerability confirmed.

How to Fix It

Fixing IDOR is not about hiding IDs — it's about enforcing control.

1. Enforce Authorization Checks

Always verify:

Does this user have access to this resource?

2. Use Access Control Mechanisms

Implement Role-Based Access Control (RBAC).

3. Avoid Direct Object References

Use indirect or mapped references where possible.

4. Validate on the Server Side

Never rely on frontend restrictions.

5. Monitor and Log Access

Detect abnormal access patterns early.

A Simple Insight That Matters

Developers often think:

"Users will only access their own data."

Attackers think:

"What happens if I change this value?"

That difference is where vulnerabilities exist.

Conclusion

IDOR is one of the simplest vulnerabilities to test — and one of the most dangerous when overlooked.

It doesn't require advanced exploitation techniques. Just curiosity, observation… and a small change.

Because sometimes, breaking security is as easy as changing a number.