Your AI Assistant Won't Remember Input Validation (You Still Have To)
By Seaworthy · 28 September 2026
Photo by Domaintechnik Ledl.net on Unsplash
I keep seeing the same thing in code reviews. A developer used an AI assistant to spin up an endpoint in ten minutes. The logic works. Tests pass. Then it ships, and within a week the service is eating 2GB of memory per request because someone POSTed a 400MB JSON body. The AI never mentioned a size limit. The developer never asked.
This is not a knock on AI coding tools. It is a knock on how we use them. Assistants are trained on an enormous pile of tutorial code, and tutorial code almost never includes input validation or request size caps. That stuff is boring. It gets cut for clarity. So the model learned to cut it too.
The failure mode is not exotic
Missing input validation and missing request size limits are two sides of the same problem: your service trusts the shape and size of whatever arrives. That trust is a gift to anyone with curl.
A few real patterns I have seen in the last year:
- A JSON endpoint with no
Content-Lengthcheck. A 50MB payload becomes a 50MB string in memory, then gets parsed into nested objects, then gets written to a log line. The process dies. - A file upload route that reads the whole stream before checking the extension. Someone sends a 1GB file named
cat.jpg. The disk fills. - A search endpoint that takes a
limitparameter with no upper bound.?limit=100000000returns everything and blocks the event loop for 90 seconds. - A webhook handler that parses XML by default. Billion laughs. You know the rest.
None of these require a clever attacker. They require a bored teenager, a misconfigured cron job, or a retry loop with a bug.
Why AI assistants make this worse
When you ask for "a route that accepts a user profile update," the model gives you exactly that. No max body size. No schema validation. No array length cap. No type coercion guard. It is not being lazy. It is being literal. The prompt did not ask for resilience.
The problem is that many developers using these tools are new to backend work, or they are frontend developers wearing a backend hat for the sprint. They do not know what they do not know. The AI output looks complete. It runs. It returns 200. That creates false confidence.
I have a strong opinion here: if you use an AI assistant to write a network-facing handler, you owe it to yourself to add three lines of defensive code before you commit. Three lines. That is the whole cost.
The fix is small and boring
Most frameworks let you set a body size limit globally. Do that first. Then validate the shape of the input with a schema library. Then cap any numeric field that could become a loop count or a database limit.
Here is a pattern in Express that I use as a default. It sets a 100KB JSON limit, rejects wrong content types, and validates with Zod.
import express from 'express';
import { z } from 'zod';
const app = express();
// 1. Global body size limit
app.use(express.json({ limit: '100kb' }));
const ProfileSchema = z.object({
name: z.string().min(1).max(200),
bio: z.string().max(2000).optional(),
tags: z.array(z.string().max(50)).max(20).optional(),
});
app.post('/profile', (req, res) => {
if (!req.is('application/json')) {
return res.status(415).json({ error: 'unsupported media type' });
}
const parsed = ProfileSchema.safeParse(req.body);
if (!parsed.success) {
return res.status(400).json({ error: 'invalid input' });
}
// use parsed.data, never req.body
return res.json({ ok: true });
});
That code is not exciting. It will never be in a conference talk. It will also stop a whole class of incidents before they start.
What to ask your AI assistant next time
When you prompt for a new handler, add a line at the end: "Include request size limits and input schema validation with explicit maximums." Watch what happens. Most models will produce something close to the code above. The knowledge is in there. It just needs a nudge.
Then check three things yourself:
- Is there a maximum on every string, array, and numeric field?
- Is there a maximum on the total request body?
- Does the handler reject unexpected content types instead of guessing?
If you cannot answer yes to all three, you are not done. The feature works, but the service is fragile.
A note on defaults
Some frameworks ship with no body limit by default. Some ship with a huge one. Do not assume. Read the docs for your server and your proxy. Nginx, for example, has client_max_body_size set to 1MB by default, but many teams raise it without thinking. Cloud load balancers have their own caps. The effective limit is the smallest one in the chain.
Resilience is not a feature you add later. It is a property of the first version. AI assistants will not remind you. That is fine. You are the one shipping the code.
If you want a second set of eyes on the operational side, Seaworthy builds tools for exactly this kind of review.
This article was generated by AI and summarises publicly available sources.
Seaworthy scans your repo for the issues covered in articles like this one.
Security gaps, exposed secrets, and misconfigurations — caught before you deploy. Free to run, no account needed.