Your AI Assistant Won't Save You From a 10GB POST Body

I keep seeing the same pattern in code written with heavy AI assistance. The endpoint works. The happy path is clean. Then someone sends a 10GB body or a JSON key that is 200,000 characters long, and the service falls over. The assistant never mentioned a size limit. It never asked about validation. It just wrote the route.

That is not a small oversight. It is the difference between an API and a liability.

The assistant writes the fun part

Ask an AI tool to build a file upload or a webhook receiver and you will get a working handler in seconds. It will parse the body, maybe check a token, and write to a database. What it will rarely do, unless you ask, is set a maximum request size, validate field types, or reject unexpected keys. The assistant optimizes for a demo that runs. It does not optimize for a service that survives contact with the internet.

I do not blame the model. I blame the workflow. We treat generated code as a finished product when it is actually a first draft that skipped the boring, defensive parts. Then we ship it because the tests pass and the demo looks good.

What missing validation actually costs

An unbounded request body is a resource exhaustion bug waiting for a bored teenager or a broken client. A single oversized POST can allocate gigabytes of memory, trigger the out-of-memory killer, and take down every other request on that instance. If you run in a container with a memory limit, one bad request kills the whole process. If you do not, one bad request kills the host.

Missing field validation is just as bad. A string field that should be 50 characters but accepts 5 million characters becomes a database bloat problem and a slow query problem. An integer field that accepts floats or negative numbers becomes a logic bug. An object field that accepts arbitrary nested JSON becomes a denial-of-service vector when your parser tries to walk it.

None of this is exotic. It is the same class of bug we have known about for decades. The difference is that AI assistants make it easy to write the handler and easy to forget the guardrails.

The fix is boring, which is why it works

Set a maximum body size at the framework or proxy level. Validate every field with a schema. Reject unknown keys. Do it before your business logic runs. Here is a small example in Node.js with Express and Zod, but the pattern applies anywhere:

import express from 'express';
import { z } from 'zod';

const app = express();

// Reject bodies over 100KB before parsing
app.use(express.json({ limit: '100kb' }));

const UserSchema = z.object({
  name: z.string().min(1).max(100),
  email: z.string().email().max(254),
  age: z.number().int().min(0).max(150),
}).strict(); // .strict() rejects unknown keys

app.post('/users', (req, res) => {
  const result = UserSchema.safeParse(req.body);
  if (!result.success) {
    return res.status(400).json({ error: 'Invalid input' });
  }
  // result.data is now typed, bounded, and safe to use
  res.status(201).json({ ok: true });
});

That is it. A size limit and a schema. Two lines of defense that catch most of the dumb stuff before it reaches your database or your memory allocator. The AI assistant could have written this. It just did not, because you did not ask.

Where to put the limits

A schema is only as good as the layer it sits in. If your reverse proxy accepts a 10GB body and streams it to your app, the app still dies, even if it would have rejected the payload a moment later. Put a hard cap at the edge first. Nginx, Envoy, Cloudflare, and most managed gateways let you set client_max_body_size or an equivalent. Pick something generous enough for real uploads and small enough that a single request cannot exhaust memory. For JSON APIs, 100KB to 1MB is plenty. For file uploads, cap the file size separately and stream it to disk instead of buffering the whole thing in memory.

Then repeat the limit inside the app, because edge configs drift and someone will bypass the proxy during local testing. The Express example above uses express.json({ limit: '100kb' }) for exactly this reason. Framework defaults vary wildly. Some parsers have no limit at all. Assume the default is unsafe until you have checked it.

Validation is not just about attackers

The instinct is to frame this as security. It is also just correctness. A well-meaning client with a bug can send a malformed payload just as easily as an attacker. If your handler assumes age is a positive integer and a mobile app sends -3, you get a corrupted record. If your schema rejects it with a 400, the client developer sees the mistake immediately and fixes it. Failures at the boundary are cheap. Failures deep in your business logic are expensive to debug and often silent for weeks.

Ask better questions

When you use an AI coding assistant, add a second prompt after the first one. Something like: "Now add request size limits and input validation for every field. Reject unknown keys. Use a schema library." You will get better code. You will also train yourself to look for the gap.

I have started treating generated code as untrusted until I see the validation layer. If it is not there, I do not merge it. That rule has saved me from more than one late-night incident.

The internet does not care that your assistant wrote the code quickly. It will send whatever it wants. Your job is to make sure your service says no before it says out of memory.

Seaworthy builds tools that help teams find these gaps in AI-assisted code before they reach production.