Cookie expiry is not session security: why secure logout still matters

A web cookie that remains in a browser after a user signs out does not prove that the account session still works. Browser storage and server-side session validity are different security questions, and confusing them turns a useful warning about token theft into a misleading verdict on logout.

The real danger arises when an attacker obtains a still-valid authentication token. If a service treats that token as proof of an authenticated session, without sender binding or another check, a copied token may allow the attacker to act within its authorised scope without entering the account password.

That threat is real, but it does not make logout obsolete or establish a universal browser vulnerability. It instead exposes the importance of server-side revocation, correctly designed session timeouts and controls that can detect or constrain token replay.

Cookie lifetime is not session lifetime

Browsers store cookies for different purposes. An authentication cookie can contain a session secret, while other cookies support preferences, analytics, advertising or shopping carts. A service can invalidate its authentication token while leaving those unrelated cookies untouched. Their continued presence does not show that the user remains logged in.

Cookies with an Expires or Max-Age attribute are persistent cookies. Those without either attribute are generally treated as session cookies, subject to browser behaviour. MDN’s cookie reference notes that browsers define when a session ends and that session-restoration features can preserve session cookies across a browser restart.

There is no single lifetime for every cookie in every browser. The current IETF 6265bis draft recommends an upper expiry limit of 400 days, but this is a qualified recommendation rather than a fixed browser rule. User agents may impose shorter limits and, in limited circumstances, longer ones.

More importantly, the date stored by the browser is not the service’s definitive security boundary. NIST says cookie expiration should not be relied upon to enforce session timeouts. A server can reject a token before its browser-side expiry date, while a poorly managed session may remain usable for as long as the server continues to accept it.

What secure logout should do

A secure logout has two related jobs. It should erase or invalidate the authenticated session on the server, then expire or remove the corresponding token held by the browser. NIST requires session secrets to be erased or invalidated when a subscriber logs out. OWASP guidance likewise makes server-side invalidation essential and recommends clearing the client token.

The server-side step is decisive. Deleting a local cookie removes that copy from the device, but it cannot retrieve a token that an attacker has already copied. Server-side revocation should make every copy of the old token unusable, including one that remains elsewhere in browser storage.

Services should also enforce idle and absolute timeouts rather than leaving validity entirely to a cookie’s expiry setting. Non-persistent authentication cookies may be practical in some contexts. The Secure, HttpOnly and SameSite attributes, along with narrow host and path scope, reduce different parts of the attack surface. None makes a stolen bearer token intrinsically harmless while it remains valid.

Federated login adds another boundary. NIST’s federation guidance distinguishes the session at a relying service from the separate session maintained by an identity provider. Signing out of one does not necessarily terminate the other, so users may need to sign out of both. That is different from a relying service failing to revoke its own authentication token.

Session replay is an operational threat

MITRE ATT&CK documents that possession of a valid web session cookie can permit access as an authenticated user without the account credentials and can bypass some MFA protocols. The attack depends on the service continuing to accept the stolen token, not merely on unrelated cookies remaining in a browser.

Microsoft supplied two operational examples in 2026. On 4 March, it reported that Tycoon2FA campaigns captured authenticated session cookies after victims completed MFA and then used those sessions without another authentication prompt. On 9 April, Microsoft documented activity it tracks as Storm-2755 replaying stolen session tokens in payroll-diversion attacks. It observed continued session use until active tokens were revoked during remediation.

These reports confirm operational abuse of session-token theft and replay. They are independent examples, not incidents connected to the BGR column that prompted this discussion, and they do not show exploitation of a universal browser flaw. The reviewed material identifies no generally affected product or version, no CVE and no associated patch.

Why MFA may not trigger again

Ordinary MFA remains valuable, but it does not necessarily cause a service to reauthenticate every request within an accepted session. Once a user has completed authentication and received a valid token, the service may accept that token later without repeating the MFA challenge. An attacker replaying a copied token can therefore inherit an authenticated session rather than defeat the MFA mechanism itself.

Phishing-resistant authentication can reduce relevant paths to session theft. Sender binding, risk-based or device-aware access controls and monitoring for anomalous token reuse can add further barriers by limiting when or where a token is accepted. These measures complement revocation and timeouts rather than replacing them.

Users can clear cookies, but providers control validity

Users should review any session controls offered by their accounts and terminate unfamiliar sessions, or all active sessions when compromise is suspected. Clearing site data is sensible on shared or potentially compromised devices, but it is not a substitute for central revocation. If token-stealing malware is suspected, the endpoint should be investigated before replacement sessions are established. Browsers and endpoint security controls should also be kept updated.

Service operators control the decisive layer. After suspected cookie theft, they should invalidate the affected server-side session, require reauthentication and issue a new token. They should also apply idle and absolute timeouts, rotate tokens where appropriate, expose useful session-review controls and monitor for suspicious reuse.

This distinction also corrects several claims in the BGR column. Blocking third-party cookies does not reliably prevent replay of a stolen first-party authentication token. BGR’s claim that unsecured public Wi-Fi offers an easy route to a user’s device was not substantiated by the reviewed evidence. OWASP guidance describes HTTPS and the Secure cookie attribute as protections against simple network interception of session cookies, although they do not address every endpoint or protocol risk.

Cookie contents are implementation-dependent, so a categorical claim that cookies do not contain personal information is unsafe. Broad statements about legal duties to offer cookie choices also require jurisdiction-specific research. No cross-browser test, authoritative prevalence data or Australian incident was identified to support wider conclusions about how often logout fails.

For a suspected token compromise, the defensive sequence is clear: revoke the affected server-side sessions, investigate the device, require the user to authenticate again and issue a replacement token. Clearing local cookies can support that response, but it cannot replace action by the service accepting the session.

Web session security becomes clearer when browser-held state and server-side trust are examined separately. Use that distinction as a starting point for broader study with The Hack Academy’s online cybersecurity training programme, which describes self-paced learning and practical exercises alongside theory, and lists cybersecurity fundamentals, networking and internet vulnerabilities.