ASVS 5.0 V4.2.5 (level 3) says that if your application, backend or frontend, builds and sends requests, it must validate, truncate or otherwise prevent creating URIs or header fields that are too long for the receiver to accept. The headline example is a very long Cookie header that makes a server answer with an error every time.
Servers set limits. Common defaults are 8 KB for the full header block in several popular servers, and a few KB for a URI. Go over and you get a 400, 413, 414 or 431 for every request.
Why it matters
This is a self inflicted denial of service, and it often persists. If your frontend keeps appending data to a cookie, such as a recently viewed list or a stack of feature flags, the cookie grows until the browser sends more than the server accepts. From then on every request fails, and the user cannot even reach the page that would clear the cookie. An attacker can trigger it for a victim by getting oversized cookies set on a shared parent domain.
Backends hit the same wall when they build an API URL from user supplied filters or put a large token in an Authorization header.
How to implement it
Set a budget for each outbound field and enforce it where the value is built.
For cookies, store an id and keep the data server side. If you must store data, cap it:
const MAX_COOKIE = 3500; // bytes, well under the 4096 browser limit
function setCookieSafe(res, name, value) {
const encoded = encodeURIComponent(value);
if (Buffer.byteLength(encoded) > MAX_COOKIE) {
throw new Error('cookie value too large');
}
res.cookie(name, encoded, { httpOnly: true, secure: true, sameSite: 'lax' });
}
For outbound URLs, move big filter sets into a POST body instead of a query string, and reject values over a fixed length:
if (url.toString().length > 2000) throw new Error('request URI too long');
On the server, configure limits deliberately (large_client_header_buffers in nginx, maxHeaderSize in Node) and make sure error pages still load without the cookies.
How to test it
Write a test that grows the value until it passes your limit and checks what happens.
big=$(python3 -c "print('a'*9000)")
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/ -H "Cookie: pref=$big"
Expect your edge to answer with a clear 4xx, and expect your own client code to refuse to build such a header in the first place. Also check that a user with an oversized cookie can still reach a page that clears it, or that the server clears it for them.
Common mistakes
- Appending to a cookie on every action with no upper bound.
- Putting search filters or ids lists into query strings that grow without limit.
- Different limits at the CDN, the proxy and the app, so the failure shows only in one place.
- Error pages that need the same oversized cookie to render.
Quick check
What is a safe way to avoid giant cookies?
Store a short session identifier in the cookie and keep the data on the server, and enforce a hard size cap in the code that sets cookies.
Sources
- OWASP Application Security Verification Standard, requirement V4.2.5 (level 3)
- RFC 6265, HTTP State Management Mechanism
