Safeguard
Application Security•

ASVS 5.0 V3.3.5: Keep Cookie Name and Value Under 4096 Bytes

ASVS V3.3.5 (Level 3) caps a cookie's name plus value at 4096 bytes so browsers keep it. Here is how to enforce the limit, test it, and stop cookie bloat.

Safeguard Security Team
4 min read

ASVS 5.0 requirement V3.3.5 says that when your application writes a cookie, the cookie name and value together must not exceed 4096 bytes. Browsers silently drop cookies above their limit, so an oversized cookie is never stored and never sent back. It is a Level 3 requirement.

The failure is quiet. A user signs in, the app tries to store a large session payload in a cookie, the browser discards it, and the next request arrives with no session. The user sees a login loop or a broken feature, and nothing in your server logs explains why.

Why it matters

This is mostly an availability and integrity problem. Cookies that grow over time, such as a signed cookie that stores a cart, permissions list or feature flags, cross the limit for some users first: the ones with the most data. Those are often your heaviest users or administrators.

There is a security angle too. If a security decision depends on a cookie that the browser dropped, the application may fall back to a default state that you did not test. A missing "consent" cookie, a missing anti-forgery cookie or a missing session cookie each produce different behavior, and some of those fall open.

Large cookies also travel on every request to the domain, including image and script requests, so they waste bandwidth and can push request headers past the limits of your proxy or web server, which then returns a 400 or 431 error.

How to implement it

Store a small identifier in the cookie and keep the data on the server. A session id of 16 to 32 random bytes is far below the limit.

If you use signed or encrypted cookie sessions, measure what you write. In Express with cookie-session, add a guard before sending:

const MAX_COOKIE_BYTES = 4096;

function setCookieSafe(res, name, value, options) {
  const size = Buffer.byteLength(name, "utf8") + Buffer.byteLength(value, "utf8");
  if (size > MAX_COOKIE_BYTES) {
    throw new Error("cookie " + name + " is " + size + " bytes, limit is " + MAX_COOKIE_BYTES);
  }
  res.cookie(name, value, options);
}

Python with Flask:

MAX_COOKIE_BYTES = 4096

def set_cookie_safe(response, name, value, **kwargs):
    size = len(name.encode("utf-8")) + len(value.encode("utf-8"))
    if size > MAX_COOKIE_BYTES:
        raise ValueError(f"cookie {name} is {size} bytes")
    response.set_cookie(name, value, **kwargs)

Note that URL encoding and base64 inflate the stored size, so measure the final encoded string, not the raw object. Keep a margin, since the browser limit applies to the full cookie including attributes in some implementations.

How to test it

Write a unit test that builds the largest realistic payload for each cookie and asserts the size. For a cookie session, build a user with the maximum number of roles, cart items or flags you allow, then check the Set-Cookie length:

curl -si https://app.example.com/profile -b cookies.txt \
  | grep -i '^set-cookie:' | awk '{print length($0)}'

Also test the failure path in a real browser. Set a 5000 byte cookie value from the console and reload. The cookie will not appear in the Application tab. Confirm your app handles the missing cookie by asking the user to sign in again rather than treating the request as trusted.

Common mistakes

Putting a JWT with every claim in a cookie. Token size grows with each role and scope. Keep claims minimal or store a reference.

Measuring only the value. The requirement counts name and value combined.

Letting many cookies pile up. Per cookie limits are only part of it. Total header size matters too, so delete cookies you no longer use.

No alerting. Log a warning when any cookie crosses, say, 3500 bytes so you see growth before users do.

Quick check

Does 4096 bytes include the attributes like Path and Expires?

The ASVS wording counts the name and value. Browsers differ on whether they also count attributes, so leave a margin below the limit.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.