This is one of those bugs that looks harmless at first glance — until you realize it’s doing exactly the opposite of what the server should be protecting itself from.
You send a very large payload.
The API responds with 400 Bad Request.
Nothing crashes.
No alerts fire.
And everyone moves on.
That response is wrong.
What was tested
Rentgen takes a known, valid API request and changes only one thing: the size of the request body.
The payload is intentionally inflated beyond reasonable limits — without breaking JSON structure, headers, or authentication.
- TEST: Large Payload Test
- Mutation: Request body size increased (configurable)
- Default size: 10 MB
- Execution: Manual, isolated test via
Runbutton - Expected:
413 Payload Too Large - Anything else: incorrect handling
The test runs independently from the rest of the suite. You explicitly choose the payload size. The default is intentionally conservative.
If your API accepts significantly more than that, it’s worth asking a very uncomfortable question: why?
The only correct response
HTTP already solved this problem.
413 Payload Too Large exists for a reason:
it tells the client that the request was well-formed,
but rejected before processing due to size constraints.
Returning 400 Bad Request is misleading.
It suggests invalid data.
It implies the client should change the payload.
And it often means the server already parsed far more than it should have.
By the time a 400 is returned,
the damage may already be done.
Why this matters
Large payload handling is not about user errors. It’s about protecting server resources.
Accepting oversized requests — even briefly — means:
- memory allocation
- CPU time spent parsing
- threads tied up doing pointless work
Multiply that by concurrent requests, and you have a denial-of-service vector that requires no authentication bypass, no malformed packets, and no exotic exploits.
What OWASP says
OWASP explicitly warns about uncontrolled resource consumption.
Excessive payload sizes fall under multiple categories:
- Denial of Service (DoS)
- Unrestricted Resource Consumption
- Improper Input Validation
The recommendation is simple: enforce strict size limits and reject oversized requests as early as possible.
That rejection should happen at the boundary — not deep inside application logic.
The real-world example
This is not theoretical.
Rentgen detected this exact issue in the ChatGPT API. Oversized payloads were accepted and processed incorrectly.
The issue was reported. OpenAI fixed it within a day.
That response speed tells you everything you need to know about the severity of the problem.
The debugging trap
Here’s how this bug usually hides:
- API works fine in normal conditions
- Clients never send huge payloads intentionally
- Load tests focus on request count, not size
- Error logs show nothing alarming
Until someone — or something — starts sending very large bodies on purpose.
At that point, the API doesn’t fail loudly. It just slows down. And then it stops responding.
What Rentgen found
In a correct implementation:
- Oversized payloads are rejected immediately
- No business logic is executed
-
The response is explicit:
413 Payload Too Large
Anything else means the server is doing work it should never have started.
Why this bug survives
Because it hides behind “reasonable assumptions”.
- “Clients won’t send that much data”
- “We already validate input”
- “This endpoint isn’t public”
None of those assumptions hold under attack.
How to fix it
The fix is boring. And that’s exactly why it works.
- Define strict payload size limits
- Enforce them at the edge (server, proxy, gateway)
- Return
413consistently - Document the limits
This is not about flexibility. It’s about survival under pressure.
Why this check exists in Rentgen
Because this bug doesn’t announce itself.
It waits quietly until someone decides to waste your resources on purpose.
Rentgen runs this test explicitly so you can see the behavior before an attacker does.
Final thoughts
APIs don’t fall over only because of complex exploits.
Sometimes they fall over because they were too polite to say: “This payload is too large.”
If your API returns 413 consistently,
you’re not being strict.
You’re being responsible.