Your service returns cookies no application code writes; where do these framework-emitted cookies come from and what do they break?

## Who writes a cookie nobody asked for Several layers can add a `Set-Cookie` to a response that no handler touched: - **The session subsystem.** The identifier cookie is created the first time anything in the request touches the session - including code that only *reads* it, or a component that stores something incidental such as a redirect target or a locale choice. One stray touch on an otherwise anonymous route gives every visitor a session. - **Request-forgery protection.** Some designs hand the token to the client in a cookie so page scripts can send it back on writes. - **Locale and time-zone resolution.** A resolver that remembers a choice generally remembers it in a cookie. - **Flash or one-shot messaging.** Where there is no server-side session, the message rides in a cookie that is written on one response and cleared on the next. - **Infrastructure in front of the application.** Reverse proxies, load balancers and edge caches add affinity or routing cookies that never pass through framework code at all, which is why the application cannot find them in its own configuration. ## Why they resist your cookie policy Each of these components carries **its own** cookie settings - name, path, domain, lifetime, security flags - resolved from its own configuration rather than from the application-level defaults your call sites inherit. Consequences worth stating in an interview: 1. **Hardening misses them.** Turning on the security flags for application cookies does not necessarily change a cookie a component emits; you have to find and set that component's own configuration. 2. **Deletions do not match.** Removing the cookie needs the name, domain and path that component chose, not the application defaults your delete helper fills in - which is why these are the cookies that keep coming back. 3. **Ownership is unclear.** The name gives no hint of which layer produced it, and a cookie added by infrastructure is invisible to every search through the application's source. ## The failure that actually costs money A response carrying `Set-Cookie` is, as a rule, not stored by shared caches - the cookie is per-client state, and a cache that served that response to a second client would hand over someone else's state. So the moment an anonymous, cacheable page begins emitting a session cookie: | Before | After | |---|---| | Edge serves most requests | Edge stores nothing for that route | | Origin sees a fraction of traffic | Origin sees all of it | | No per-visitor server state | One session entry per visitor, including crawlers | The change that causes it is usually tiny and unrelated - a new component added to the chain that reads the session, a template helper that touches it, an error handler that stores a message. Nothing fails, latency creeps up, the session store grows, and the cause is several deploys back. ## How to investigate 1. **Look at raw response headers per route.** Use a client that prints every `Set-Cookie` line, on an anonymous request with no cookie jar, for a route that should emit none. 2. **Compare routes.** A route that emits nothing and a route that emits a session cookie differ by whichever component runs on one and not the other. 3. **Bisect the chain.** Disable or reorder the components that can write cookies and re-request; the one whose removal silences the header is the author. 4. **Ask whether the session was touched at all**, rather than whether anything wrote to it - creation is triggered by access in many designs, not by mutation. 5. **If nothing in the application accounts for it**, request the origin directly and compare with the response through the proxy; a cookie that appears only through the proxy was added there. ## Controlling them - Keep anonymous, cacheable routes off any component that touches session state, and assert it: a test that requests such a route and fails if the response carries any `Set-Cookie` is cheap and catches the regression at the commit that introduces it. - Configure each emitting component explicitly - name, scope, flags - rather than assuming it inherits application defaults. - Record the full inventory of cookies your service can emit, with the owner of each. It is the document that makes a later deletion, a scope change or a security review possible. - Keep application cookies and component cookies on the same small set of scopes, so one deletion routine can cover both.