Your AI Assistant Won't Save You From a Missing Request Size Limit

I keep seeing the same pattern in code reviews. A developer asks an AI assistant to write an Express endpoint, the assistant produces something clean, and the developer ships it without checking whether the request body has any size cap. The code works. It also accepts a 500 MB JSON payload and tries to parse it. That is not a security feature. It is a denial-of-service invitation.

This is not a knock on AI coding assistants. They are good at generating plausible code. But plausible code often omits the boring operational details. Input validation and request size limits are boring. They are also the difference between an API that survives a bad day and one that falls over because someone sent a malformed request with a huge body.

The default is often unlimited

Many web frameworks do have default body size limits. Express, for example, defaults to 100 KB for express.json() and express.urlencoded() since version 4.16.0. That is a reasonable start. But AI assistants frequently generate code that overrides this, or they use a framework where no default exists. A common snippet looks like this:

app.use(express.json());
app.post('/upload', (req, res) => {
  // process req.body
});

That default limit applies globally. If you need larger payloads on one route, you might be tempted to remove the limit entirely. I have seen assistants suggest express.json({ limit: '50mb' }) for convenience. That is fine for a specific endpoint, but it is a disaster if applied to every route. Worse, some developers copy that snippet into a shared middleware and forget it.

Other frameworks are less forgiving. Go's net/http has no built-in body size limit. You have to wrap r.Body with http.MaxBytesReader. Python's Flask does not limit request size by default. Django has DATA_UPLOAD_MAX_MEMORY_SIZE but it is not a hard cap for all cases. Node's raw http module gives you a stream and no guardrails.

Why this matters for resilience

A missing size limit is not just a potential security hole. It is a resilience problem. One large request can exhaust memory, block the event loop, or cause the process to crash. If you run multiple instances behind a load balancer, one bad request can take down a worker, then another, until the service is unavailable. This is not theoretical. I have seen a single 200 MB JSON payload cause a Node process to run out of heap and restart, taking down a dozen other in-flight requests.

Input validation goes hand in hand with size limits. Even a small payload can contain fields that break your logic. An AI assistant might generate a route that trusts req.body.userId as a number without checking. If someone sends a string, your database query might fail, or worse, inject something. The assistant does not know your threat model. You do.

A better pattern

The fix is not complicated. Set a global limit that is small enough to prevent abuse but large enough for normal traffic. Then override it only where you truly need larger payloads, and validate the content type and schema before processing.

Here is an example in Express:

const express = require('express');
const app = express();

// Global limit: 100 KB
app.use(express.json({ limit: '100kb' }));

// Specific route with a larger limit
app.post('/upload', express.json({ limit: '10mb' }), (req, res) => {
  if (!req.is('application/json')) {
    return res.status(415).send('Unsupported Media Type');
  }
  // validate req.body.shape here
  res.send('ok');
});

For Go, use http.MaxBytesReader:

func handler(w http.ResponseWriter, r *http.Request) {
  r.Body = http.MaxBytesReader(w, r.Body, 1<<20) // 1 MB
  if err := r.ParseForm(); err != nil {
    http.Error(w, "Request too large", http.StatusRequestEntityTooLarge)
    return
  }
  // process
}

For Flask, set MAX_CONTENT_LENGTH:

app.config['MAX_CONTENT_LENGTH'] = 1 * 1024 * 1024  # 1 MB

These are not exotic changes. They are three lines of code. But they require you to think about limits before you ship.

What I want you to do

Next time you ask an AI assistant to write an endpoint, ask it one more question: "What is the request size limit here, and where is input validation?" If the answer is vague, add it yourself. Do not assume the assistant handles it. Do not assume the framework handles it. Check the defaults. Write a test that sends a 10 MB payload and confirm you get a 413. Write a test that sends a malformed field and confirm you get a 400.

This is not about paranoia. It is about respecting the operational reality of running a service. AI assistants can speed up coding, but they cannot replace the judgment that comes from knowing your system's failure modes. Missing validation and missing size limits are two of the easiest failure modes to prevent. They are also two of the most common.

If you want a starting point, Seaworthy offers a set of baseline checks for API resilience, including request size limits and input validation patterns.