While testing a web application, I discovered a vulnerability that allowed unauthorized modification of user profiles. At first glance, the functionality seemed harmless — a simple "change username" feature.

However, deeper analysis revealed a critical flaw in how the backend handled authorization.

By combining exposed user identifiers with improper validation of Bearer tokens, I was able to modify the profile data of other users — leading to a classic IDOR (Insecure Direct Object Reference) vulnerability with significant real-world impact.

Target Overview:-

  • Platform: Web Application
  • Feature: Profile Name Update
  • Authentication: Bearer Token (Authorization Header)
  • Testing Method: Manual testing using an intercepting proxy

The application allows authenticated users to update their profile name via an API request.

Recon & Key Observation:-

To begin testing, I created two accounts:

  • Victim Account
  • Attacker Account
None
None

While exploring the application, I noticed that each user had a unique identifier (user_id), which was exposed in the chat functionality.

This was an important finding — because predictable or accessible identifiers often open the door to IDOR vulnerabilities.

Vulnerability Details:-

The application sends a request similar to the following when updating a profile:

PUT /api/updateprofile/IlfzOPlrvdUb0yKOhfCSvMuQTs92 HTTP/1.1

Authorization: Bearer <token> {"name":"victim 2",

"Company":"No company",

"profilepicurl":

"https://api.dicebear.com/7.x/notionists/svg?seed=janorom162&backgroundColor=ffd5dc","jobTitle":"","about":"","isSearchable":true,"isPublic":true} }

None

The Core Issue:-

  • The server authenticates the request using the Bearer token
  • But it does not verify whether the provided user_id belongs to the authenticated user

This means any authenticated user can modify any other user's profile by simply changing the user_id.

Exploitation Process:-

The vulnerability can be exploited with the following steps:

1. Capture a Legitimate Request:

Log in as the attacker and intercept the profile update request:

{

"name":"attacker 2",

"Company":"No company",

"profilepicurl":"https://api.dicebear.com/7.x/notionists/svg?seed=dojofa2596&backgroundColor=ffdfbf",

"jobTitle":"",

"about":"",

"isSearchable":true,

"isPublic":true

}

None

2. Obtain Victim's User ID:

Navigate to the chat section and identify the victim's user_id, which is exposed through the application.

None

3. Modify the Request:

Replace the attacker's ID with the victim's ID:

PUT /api/updateprofile/IlfzOPlrvdUb0yKOhfCSvMuQTs92 HTTP/2

None

4. Send the Request

Forward the modified request using the attacker's Bearer token.

None

Result

The server successfully processes the request and updates the victim's profile name, even though the attacker is not authorized to perform this action.

None

Impact

Although this vulnerability affects a "profile name" feature, its real-world implications are much more serious:

  • Unauthorized modification of any user account
  • User impersonation in chat systems
  • Targeted social engineering attacks
  • Mass account defacement via automation
  • Platform trust degradation

Because user identity is central to communication features, this issue can directly impact how users interact and trust the platform.

CVSS v3.1 Score

Base Score: 7.1 (High)

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N

🧾 Justification

  • Low complexity attack with no user interaction
  • Requires only a valid account
  • User IDs are easily accessible (no brute force needed)
  • High integrity impact due to unauthorized data modification
  • Potential for chaining with other vulnerabilities

Root Cause

The vulnerability exists due to:

  • Missing object-level authorization checks
  • Trusting user-supplied user_id values
  • Exposure of sensitive identifiers in the chat module
  • Over-reliance on authentication without enforcing authorization

Mitigation & Recommendations

To fix this issue, the application should:

  • Enforce strict server-side authorization checks
  • Derive user identity from the Bearer token instead of request parameters
  • Ensure users can only modify their own data
  • Avoid exposing sensitive identifiers unnecessarily
  • Implement proper access control validation on all endpoints

Responsible Disclosure

This vulnerability should be reported through the appropriate responsible disclosure or bug bounty program to ensure it is fixed and does not impact users.

Conclusion

This case highlights a critical security lesson:

Authentication does not equal Authorization

Even when modern authentication mechanisms like Bearer tokens are used, failing to enforce proper authorization can lead to serious vulnerabilities.

Final Thoughts

Simple features often hide critical flaws.

Always test beyond the surface:

  • Inspect requests carefully
  • Analyze headers and tokens
  • Look for exposed identifiers
  • And most importantly — never trust the backend blindly