Your API Returns 400 for Huge Payloads? Congratulations. You Just Built a Polite DoS Gateway

There's a deceptively dangerous API behavior that appears harmless: returning 400 Bad Request for oversized payloads instead of the correct 413 Payload Too Large response. This seemingly minor mistake transforms your API into a polite denial-of-service gateway.

The Resource Drain Mechanism

When an API receives a request exceeding payload limits but returns 400:

1. Memory allocation occurs for the entire payload
2. JSON parsing/validation executes
3. CPU cycles process the invalid request
4. Worker threads remain occupied until completion

By returning 400, you imply the client sent malformed data, not that the request exceeded size limits. This distinction forces your server to fully process the request before rejecting it. Attackers exploit this by flooding endpoints with valid-but-oversized payloads, consuming resources without triggering security alerts.

The Rentgen Validation Test

This vulnerability led to creating the Large Payload Test in Rentgen. It sends intentionally oversized but structurally valid requests to APIs. The only acceptable response is 413 at the network edge - before any processing occurs. Any other response, including 400, indicates the server is wasting resources on invalid requests.

Real-World Impact: ChatGPT API Case

This isn't theoretical. The ChatGPT API had this exact vulnerability. When researchers sent oversized payloads:

• Servers fully parsed JSON
• Executed validation logic
• Returned 400 after resource consumption

Attackers could've used this to degrade service. OpenAI fixed it within 24 hours of reporting - demonstrating the severity.

Why This Vulnerability Persists

Human assumptions enable this anti-pattern:

1. "Clients won't send huge payloads" (attackers will)
2. "Our validation handles it" (but runs too late)
3. "Internal APIs are safe" (lateral attacks exist)

The Boring (But Critical) Fix

1. Define limits: Set strict max_payload_size per endpoint
2. Enforce early: Reject oversize requests at the load balancer/reverse proxy
3. Return 413 consistently: Use standardized response for all size violations
4. Document limits: Include size constraints in OpenAPI specs