A logout handler runs `document.cookie = "session=; max-age=0"`, but the cookie is still sent on the next request. Give every reason a JavaScript cookie deletion can silently fail, and the correct way to delete one.

## There is no delete operation The `document.cookie` API exposes exactly two operations, read-all and write-one. Deletion is expressed as a write whose effect is immediate expiry: ```js document.cookie = 'session=; path=/; max-age=0'; // equivalently document.cookie = 'session=; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT'; ``` The value is irrelevant — the browser removes the cookie because its lifetime has already elapsed. `Max-Age=0` and a past `Expires` are equivalent; `Max-Age` wins if you supply both. ## Cookie identity is a triple A cookie is keyed by **name + domain + path**, not by name alone. Two cookies named `session`, one at `Path=/` and one at `Path=/app`, are two distinct entries that both appear as `session=...` when you read the jar. A write only replaces an existing cookie when all three parts match; otherwise it **creates a new one**. That is exactly what the failing handler does. Run on `/app/logout` with no `path` attribute, the default path becomes `/app`, so the browser either expires an `/app`-scoped `session` that never existed or briefly creates and drops one. The `/`-scoped cookie the server set is untouched and continues to be sent. ```js // On /app/logout document.cookie = 'session=; max-age=0'; // targets /app — wrong cookie document.cookie = 'session=; path=/; max-age=0'; // targets / — correct ``` The symmetrical trap is `Domain`. A cookie set with `Domain=example.com` is shared across subdomains; one set with no `Domain` is host-only for exactly `app.example.com`. Deleting requires matching that choice: ```js document.cookie = 'session=; path=/; domain=example.com; max-age=0'; ``` And because the getter never returns attributes, **there is no way to find out** which of the two variants exists. You cannot inspect your way to the answer; the code that wrote the cookie must know the scope, which is the argument for routing every cookie write and delete through one helper that carries the scope with the name. ## Failures script cannot fix at all - **`HttpOnly`.** Script cannot read, modify, or expire such a cookie. A same-named write creates or touches a separate non-HttpOnly cookie while the real one survives. Logout must be a server request answered with `Set-Cookie: session=; Path=/; Max-Age=0`. - **`Secure` from an insecure page.** A page on `http:` cannot overwrite a `Secure` cookie, so the delete is dropped. - **Name prefixes.** A cookie named `__Host-session` or `__Secure-session` is only accepted by the browser when the write carries the attribute set its prefix requires; a delete write that omits them is rejected like any other non-conforming write, and the cookie stays. - **Nothing reports any of this.** The setter returns nothing and throws nothing, so every one of these failures is silent. ## Verifying, and its limits Read the jar back: ```js function deleteCookie(name, { path = '/', domain } = {}) { const d = domain ? `; domain=${domain}` : ''; document.cookie = `${name}=; path=${path}${d}; max-age=0`; return !document.cookie.split('; ').some((p) => p.startsWith(name + '=')); } ``` This tells you whether *a* cookie of that name is still visible — useful, but it cannot distinguish "deleted" from "there was a second one at another path", and it says nothing about HttpOnly cookies, which were never visible. A robust logout therefore does not rely on client-side deletion at all: it calls the server, lets the server expire its own cookies, and treats the subsequent `401` as the state transition. Client-side deletion is for cookies script itself created — a UI preference, an A/B bucket, a dismissed-banner marker. ## The shortcut people reach for, and why it is wrong "Loop over `document.cookie` and expire everything" fails for the same reasons: it can only see script-visible cookies, it does not know their paths, and it will happily leave duplicates at other scopes. If a flow genuinely needs the whole origin cleared, that is a server-side sign-out plus, at most, expiring the specific cookies you own with the scopes you recorded when you wrote them.