Four IDORs, One Target: Broken Access Control in a Gaming Platform ⭐

In this write-up, I'm going to describe four IDOR (Insecure Direct Object Reference) vulnerabilities that I discovered in one of the relatively large gaming platforms for PC and mobile games.

What is IDOR?

Before going into the details, let's first understand what IDOR is and why it is dangerous.

IDOR, or Insecure Direct Object Reference, is a vulnerability that belongs to the Broken Access Control category. It occurs when the server trusts user-supplied identifiers (such as IDs) without properly verifying whether the user is authorized to access or modify that resource.

As a result, an attacker can simply change an ID in a request and access or modify other users' sensitive information.

In this case, I found four IDOR vulnerabilities: two in the Profile section and two in the Game Account section.

First IDOR — Profile Information Disclosure

When a user opened the profile page, the following request was sent to the API:

GET /api/profile/123

GET /api/profile/123

The server responded with a JSON object:

{
  "Username": "Arshia",
  "PhoneNumber": "0123456789",
  "Email": "example@gmail.com",
  "Image": "/api/profile/image/1.jpg"
}

{
  "Username": "Arshia",
  "PhoneNumber": "0123456789",
  "Email": "example@gmail.com",
  "Image": "/api/profile/image/1.jpg"
}

To understand how user IDs were generated, I created a new account and noticed that user IDs were sequential. For example, if my first account ID was 123, the next one would be 124.

At this point, I simply changed the ID value in the request.

Original request:

GET /api/profile/123

GET /api/profile/123

Modified request:

GET /api/profile/125

GET /api/profile/125

Response:

{
  "Username": "Victim",
  "PhoneNumber": "052123254",
  "Email": "vicyim@gmail.com",
  "Image": "/api/profile/image/victim.jpg"
}

{
  "Username": "Victim",
  "PhoneNumber": "052123254",
  "Email": "vicyim@gmail.com",
  "Image": "/api/profile/image/victim.jpg"
}

Without any authorization checks, the server returned another user's profile data, confirming the IDOR vulnerability.

Second IDOR — Profile Update

The second vulnerability existed in the profile update functionality.

The issue was exactly the same, but in this case, it was possible not only to view other users' data but also to modify it.

At first, I tried changing users' phone numbers since they were used for login, which could potentially lead to account takeover. However, the system did not allow changes to phone numbers.

Even so, other profile fields were still editable, showing a lack of proper server-side access control.

Third IDOR — Game Account Information

This platform had a feature that allowed users to link their game accounts to the website so they could easily purchase in-game items without re-entering their credentials.

For example, when a user wanted to buy CP for a Warzone account, they would store their game login details in this section.

When viewing the game account information, the following request was sent:

GET /api/game/123

GET /api/game/123

Server response:

{
  "Username": "test",
  "Email": "test@gmail.com",
  "Password": "test123",
  "Level": 200
}

{
  "Username": "test",
  "Email": "test@gmail.com",
  "Password": "test123",
  "Level": 200
}

The same issue was present here as well.

By simply changing the ID in the request, it was possible to access other users' game account data without any restrictions.

Since sensitive information such as email and even passwords were returned in the API response, this vulnerability could have led to large-scale account compromise.

Fourth IDOR — Game Account Information

The fourth vulnerability was in the profile update functionality. By simply changing the profile ID, I was able to modify the game profile of any user.

Conclusion

In total, four IDOR vulnerabilities were identified across two main areas of the application:

Viewing user profile information
Updating user profile information
Viewing game account information
Updating game account information

The root cause of all these issues was missing or improper authorization checks on the server side. As a result, simply modifying the object ID in the request allowed access to other users' data.

This was one of the most interesting findings I've worked on so far, and I hope this write-up is helpful for anyone learning IDOR testing.

Contents