Listen to this Post
Introduction
Many modern web applications implement role-based access control (RBAC) exclusively on the frontend, creating a dangerous illusion of security. As demonstrated by a recent $800 bug bounty finding, when backend APIs lack proper authorization checks, a low-privileged user (e.g., a “Student”) can replay previously authorized requests after being downgraded from a higher-privileged role (e.g., “Moderator”), leading to vertical privilege escalation. This article dissects the technical root cause, provides step‑by‑step exploitation techniques, and offers hardened code and command‑line examples to help penetration testers and defenders close this critical gap.
Learning Objectives
- Understand how frontend‑only role enforcement enables replay attacks and vertical privilege escalation.
- Learn to manually test and exploit missing backend API authorization using Burp Suite,
curl, and custom scripts. - Implement server‑side RBAC middleware, JWT claim validation, and anti‑replay mechanisms to mitigate the flaw.
You Should Know
- Frontend vs. Backend Authorization – The Root Cause
The vulnerability arises when developers assume that hiding UI elements (buttons, menus) for restricted roles is sufficient. In reality, the backend API must independently verify the requester’s current privileges on every request. If the backend only checks that a request is syntactically valid (e.g., a valid session token) but not whether the user still holds the required role, an attacker can capture a privileged request (e.g., promoting a user) while acting as a Moderator, then replay that exact request after their role is downgraded to Student.
Step‑by‑step guide to understand the flow:
- Attacker logs in as a Moderator and performs a sensitive action (e.g.,
PUT /api/roles/assign). - Using a tool like Burp Suite, they capture the request and send it to Repeater.
- The attacker’s role is downgraded to Student (e.g., by an admin or through a separate vulnerability).
- The backend session still holds a valid token, but the user’s role in the database changes. If the API does not re‑evaluate the role from the database or token claims on each request, the replayed request succeeds.
- Result: A Student can still assign moderator privileges – vertical privilege escalation.
-
Exploiting the Flaw – Step‑by‑Step Replay Attack (Burp Suite +
curl)
This practical guide uses Burp Suite Community Edition and `curl` on Linux (or WSL for Windows). The same principles apply to any API testing framework.
Prerequisites:
- Target application with role‑based endpoints.
- Two accounts: one with elevated role (Moderator), one low role (Student).
- Burp Suite proxy configured on
127.0.0.1:8080.
Steps:
1. Capture the privileged request
Log in as Moderator, perform the action (e.g., deleting a user). In Burp Suite, go to Proxy → HTTP History, right‑click the request, and select Send to Repeater.
2. Verify the request works
In Repeater, click Send. A `200 OK` or `204 No Content` confirms the API is functional.
3. Downgrade your role
Log out of the Moderator account. Log in as Student. In a separate browser or incognito window, confirm that the UI no longer shows the “Delete User” button. However, the backend session token (if still active) might remain valid. If the app uses stateless JWTs, the token still contains the old role claim unless the server forces re‑issuance on role change.
4. Replay the captured request
Copy the session cookie or `Authorization: Bearer
curl -X DELETE 'https://target.com/api/admin/users/123' \ -H 'Cookie: session=MODERATOR_SESSION_COOKIE' \ -H 'X-Requested-With: XMLHttpRequest'
If the server does not re‑validate the current role, the deletion succeeds even though you are now a Student.
5. Test vertical escalation
Attempt to assign a higher role using the replayed request:
curl -X POST 'https://target.com/api/roles/assign' \
-H 'Content-Type: application/json' \
-H 'Cookie: session=STUDENT_SESSION' \
-d '{"user_id": "victim", "role": "moderator"}'
If successful, the API is critically broken.
- Linux / Windows Commands for Automated Replay & Fuzzing
Use these command‑line tools to scale the test across multiple endpoints.
Linux (bash):
Extract all API endpoints from a captured Burp log (exported as burp_export.xml):
grep -oP '(?<=<url>).?(?=</url>)' burp_export.xml | sort -u > endpoints.txt
Replay each endpoint with a downgraded session token:
while read url; do
curl -X GET "$url" -H "Cookie: session=STUDENT_SESSION" -s -o /dev/null -w "%{http_code} $url\n"
done < endpoints.txt
Windows (PowerShell):
Replay a specific POST request with a captured token:
$headers = @{
"Authorization" = "Bearer $env:MODERATOR_TOKEN"
"Content-Type" = "application/json"
}
$body = '{"action":"promote","user":"attacker"}'
Invoke-RestMethod -Uri "https://target.com/api/admin/action" -Method Post -Headers $headers -Body $body
- Vulnerable vs. Fixed API Endpoint (Python Flask Example)
Vulnerable code (only frontend restriction):
@app.route('/api/delete_post', methods=['POST'])
@login_required
def delete_post():
NO role check – any logged-in user can delete any post
post_id = request.json['post_id']
delete_post_from_db(post_id)
return 'Deleted', 200
Fixed code with middleware RBAC:
from functools import wraps
def role_required(required_role):
def decorator(f):
@wraps(f)
def decorated(args, kwargs):
user_role = get_current_user_role() Always query DB or fresh token claims
if user_role != required_role:
return jsonify({"error": "Forbidden"}), 403
return f(args, kwargs)
return decorated
return decorator
@app.route('/api/delete_post', methods=['POST'])
@login_required
@role_required('moderator')
def delete_post():
Now only moderators can delete
...
5. Mitigation Strategies – Server‑Side RBAC & Anti‑Replay
Implement these layers to stop vertical privilege escalation:
- Always re‑validate roles on the backend – Do not trust client‑side hints. Use a middleware that checks the user’s current role from a secure session store (e.g., Redis) or from a signed JWT that is short‑lived and re‑issued after any role change.
- Include a nonce or request hash – For sensitive actions, require a unique, one‑time token (e.g., a CSRF token that is tied to the user’s current role). This breaks replay attacks.
- Audit logs & anomaly detection – Monitor for requests where the role in the token differs from the role in the session store.
Example: Adding a nonce to a request (Node.js/Express):
// Server generates a nonce and stores it in the user's session
app.post('/api/sensitive-action', (req, res) => {
const { nonce } = req.body;
if (nonce !== req.session.expectedNonce) {
return res.status(403).send('Invalid nonce');
}
// After use, invalidate the nonce
req.session.expectedNonce = crypto.randomBytes(16).toString('hex');
// Proceed with action
});
- Cloud Hardening – API Gateway & IAM Policies
In cloud environments (AWS, Azure, GCP), offload authorization to the API gateway:
- AWS API Gateway + Lambda authorizers – Write a custom authorizer that extracts the user’s current role from DynamoDB or Cognito before allowing the request to reach the backend.
- Azure API Management – Use policy expressions to validate JWT claims and reject requests where the `role` claim does not match the required value for the specific endpoint.
Example AWS Lambda authorizer policy (pseudocode):
def lambda_handler(event, context): token = event['authorizationToken'] user_id = decode_jwt(token)['sub'] current_role = get_role_from_db(user_id) fresh DB lookup if current_role != 'moderator': return generate_policy(user_id, 'Deny', event['methodArn']) return generate_policy(user_id, 'Allow', event['methodArn'])
7. Vulnerability Exploitation & Mitigation – Real‑World Impact
The $800 bounty described by Shivang Maurya illustrates a common pattern: developers implement “security” by hiding buttons, but leave the underlying API completely exposed. Attackers can exploit this by:
– Using browser devtools to find hidden API endpoints.
– Replaying captured requests with tools like Burp Suite, OWASP ZAP, or even simple `curl` scripts.
– Escalating privileges from a standard user to admin without ever triggering a frontend error.
Mitigation in CI/CD:
Add automated API security tests that:
1. Log in as a low‑privilege user.
- Attempt to call high‑privilege endpoints using tokens or cookies obtained from a high‑privilege session.
- Fail the build if any endpoint returns `2xx` instead of
403.
What Undercode Say
- Key Takeaway 1: Frontend role‑based UI restrictions are never a substitute for backend authorization. Every API endpoint must independently verify the caller’s current privileges on each request.
- Key Takeaway 2: Replay attacks after role downgrade are a direct consequence of relying on stale session data or stateless JWTs without role re‑validation. Short token lifetimes and nonce‑based request signing are effective countermeasures.
Analysis: The bug bounty finding underscores a systemic issue in web development education – many tutorials focus on UI/UX role hiding but omit server‑side enforcement. As APIs become the backbone of modern applications, this flaw will continue to yield high‑impact vulnerabilities. Defenders should adopt a “zero trust” approach to authorization: never trust the client, always verify the current role from a trusted source (database or short‑lived, claim‑refreshing token). Penetration testers should actively search for endpoints that lack explicit role annotations, as they often represent low‑hanging fruit with critical impact.
Prediction
As API‑first architectures and microservices proliferate, the frequency of “frontend‑only authorization” flaws will initially rise, driven by time‑to‑market pressures. However, with the increasing adoption of automated API security testing tools (e.g., Burp Suite Pro’s BCheck, 42Crunch, OWASP ZAP’s policy rules) and the integration of RBAC validation into OpenAPI specifications (via `x-security` extensions), these bugs will become less common. The long‑term shift will be toward declarative authorization frameworks (e.g., Open Policy Agent) and service meshes that enforce policies at the network layer, making it impossible to bypass backend checks through request replay. Until then, bug bounty programs will continue to reward sharp testers who spot the gap between what the UI shows and what the API allows.
▶️ Related Video (74% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Shivangmauryaa Bounty – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
