Listen to this Post
Introduction:
Modern APIs often support multiple data formats like JSON and XML to cater to diverse clients. However, when authorization logic is inadvertently tied to the expected content type, attackers can manipulate the `Content-Type` header to bypass security controls. This article dissects a real-world bug bounty discovery where changing `Content-Type` from `application/xml` to `application/json` and sending an empty JSON body allowed a low‑privileged user to retrieve sensitive administrative data—a classic case of insecure API design.
Learning Objectives:
- Understand how inconsistent content‑type handling can lead to authorization bypasses.
- Learn to test for content‑type manipulation vulnerabilities using common tools.
- Implement effective mitigations to secure API endpoints against such attacks.
You Should Know
1. The Vulnerability: When Content‑Type Dictates Access
APIs that accept multiple formats (e.g., XML and JSON) often use different parsers. If the authorization check is only performed when a specific format is detected—or if the parser incorrectly maps the request to a higher‑privileged context—an attacker can switch the `Content-Type` header to trick the API. In the bug bounty example, the endpoint expected XML for admin functions but accepted JSON without re‑validating privileges. Sending `{}` with `Content-Type: application/json` returned admin‑level data to a standard user.
2. Step‑by‑Step Testing Methodology
Step 1: Identify endpoints supporting multiple formats.
Use a tool like Burp Suite to spider the application and note endpoints that accept both `application/xml` and `application/json` (look at `Accept` headers or API documentation).
Step 2: Capture a legitimate XML request.
Send a valid XML request to a privileged endpoint (e.g., /api/admin/users) and observe the normal response.
Step 3: Change `Content-Type` to `application/json`.
Modify the request header:
`Content-Type: application/json`
Step 4: Replace the body with an empty JSON object.
`{}`
Step 5: Resend the request as a low‑privileged user.
If the API mistakenly associates the new content type with a different (or no) authorization handler, sensitive data may leak.
Example `curl` commands:
Original XML request (admin user)
curl -X POST https://target.com/api/admin/data \
-H "Content-Type: application/xml" \
-d '<request><id>123</id></request>' \
-H "Cookie: session=admin_cookie"
Attack as low‑privileged user
curl -X POST https://target.com/api/admin/data \
-H "Content-Type: application/json" \
-d '{}' \
-H "Cookie: session=low_priv_cookie"
Windows PowerShell equivalent:
Invoke-RestMethod -Uri "https://target.com/api/admin/data" `
-Method Post `
-Headers @{"Content-Type"="application/json"; "Cookie"="session=low_priv_cookie"} `
-Body "{}"
3. Tool‑Assisted Exploitation
- Burp Suite: Intercept a request, right‑click → “Change request method” or manually edit the header. Use the Repeater tool to resend with modified `Content-Type` and payload.
- Postman: Create a request, set header to
application/json, add an empty JSON body, and send with a low‑privilege token. - Automated scanning: OWASP ZAP’s “Active Scan” can detect such misconfigurations by fuzzing headers and observing response anomalies.
4. Why This Works: Code‑Level Analysis
Consider a vulnerable controller snippet (pseudo‑Java Spring):
@RequestMapping(value = "/admin/data", method = RequestMethod.POST,
consumes = {MediaType.APPLICATION_XML_VALUE, MediaType.APPLICATION_JSON_VALUE})
public ResponseEntity getAdminData(@RequestBody String body) {
if (request.getContentType().equals(MediaType.APPLICATION_XML_VALUE)) {
// Admin privilege check
if (!hasAdminRole()) return forbidden();
return processXml(body);
} else {
// JSON handling without privilege check – vulnerability!
return processJson(body);
}
}
Here, the JSON branch bypasses the admin check. The attacker simply flips the content type to reach the unguarded path.
5. Mitigation Strategies for Developers
- Enforce strict content‑type validation: Use an allowlist (e.g., only
application/json) and reject any unsupported type with a406 Not Acceptable. - Decouple authorization from content negotiation: Perform privilege checks before dispatching to any content‑specific handler.
- Use framework‑provided validation: In Spring, use `@RequestMapping(consumes = “application/json”)` exclusively; avoid mixing types on sensitive endpoints.
- Web server configuration: Block unexpected content types at the edge. For Nginx:
location /api/admin/ { if ($http_content_type !~ "^application/json$") { return 406; } proxy_pass http://backend; } - API gateway: Tools like Kong or AWS API Gateway can enforce content‑type policies before requests reach the application.
6. Advanced Exploitation: Combining with Other Attacks
Content‑type manipulation is often a stepping stone. If the backend still parses the request as XML after a header change, it may be vulnerable to XXE (XML External Entity) attacks. Test with:
<?xml version="1.0"?> <!DOCTYPE root [<!ENTITY xxe SYSTEM "file:///etc/passwd">]> <root>&xxe;</root>
Send this with Content-Type: application/xml; if the API accepts it, an attacker can read local files. This highlights the importance of disabling external entity processing.
7. Continuous Testing & Monitoring
- CI/CD integration: Run API security tests with tools like
dredd,postman/newman, or OWASP ZAP in your pipeline. - Logging: Monitor for requests with mismatched `Content-Type` and body formats; alert on patterns that attempt bypasses.
- Bug bounty programs: Encourage researchers to test for content‑type manipulation by explicitly including it in the scope.
What Undercode Say
- Key Takeaway 1: Content‑type manipulation is a low‑hanging fruit in API testing—always verify that authorization is not bound to the expected request format.
- Key Takeaway 2: Defensive coding must separate content negotiation from access control; otherwise, a simple header change can expose privileged data.
This bug bounty example underscores a recurring theme: API developers often trust client‑supplied headers implicitly. The fix is not complex—enforce strict content‑type validation at the application or gateway level, and ensure that every endpoint performs authorization checks regardless of the incoming format. With APIs becoming the backbone of modern applications, such oversights can lead to catastrophic data leaks.
Prediction
As organizations increasingly adopt microservices and GraphQL, the attack surface for content‑type confusion will expand. Attackers will automate fuzzing of headers to uncover similar misconfigurations. We predict that content‑type manipulation will remain a top‑10 API risk for the next few years, driving adoption of API security gateways and stricter schema validation. Proactive testing and developer training will be essential to prevent these seemingly trivial but highly impactful vulnerabilities.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Aniket Bhutani – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
