Window Name

How window name works

The window.name property belongs to the browser’s browsing context, not to a single document. That makes it unusual: a page can set a string on a window, navigate away, and the next page loaded into that same context can still read it. In practice, that persistence is why it has been used for cross-page targeting, but also why it can become a hidden data channel.

Because the value is just a string, it is easy to treat it as harmless metadata. In reality, anything stored there should be assumed readable by later content that gains the same browsing context, including content from a different origin after navigation. That design is useful for legitimate window targeting, but it also creates a trust boundary that is easy to overlook.

Why window name can create security exposure

The security concern is not the property itself, but the fact that it can outlive the page that wrote it. If sensitive data, session hints, user identifiers, or routing information are placed into the value, later pages may inherit it unintentionally. That can create cross-origin data exposure, unexpected coupling between sites, or a convenient place for an attacker-controlled page to recover information left behind by another application.

This is especially risky when developers use the property as a lightweight state store instead of as a naming mechanism. The browser does not treat the string as confidential, and it does not automatically clear it when the origin changes. As a result, the value can become a stale shared artifact across navigation boundaries.

Safer uses and design boundaries

Used narrowly, window.name can still be legitimate for targeting or reusing a named browsing context. The safe pattern is to keep the value non-sensitive, short-lived, and disposable, with the understanding that the browser may preserve it longer than the current document lifecycle. Treat it as a convenience feature for window identity, not a storage layer.

Designers should also assume that any state placed there may be observed by content loaded later in the same tab or popup. If the application needs to carry data between pages, it is safer to use an explicit application flow that does not rely on browser persistence across origins. That keeps the trust boundary visible instead of hidden inside a browser implementation detail.

When to treat window name as a problem

Window naming becomes problematic when it is used to transport secrets, user data, redirect targets, or application state that would be unsafe to expose to later content. It is also a concern when a page assumes the value is isolated to one site, because browser navigation semantics do not guarantee that assumption.

For threat modeling, the important question is whether an untrusted page can inherit a named browsing context and read or overwrite the stored string. If yes, the property should be handled as shared state with a clear exposure path, not as private memory.

Risk and Threat Considerations

Window name is risky when applications use it as an implicit data channel across navigations, because the browser preserves the value even after the origin changes. That persistence can leak routing data or other sensitive context into a later page that was never meant to see it.

Failure mechanism: A trusted page writes information into the browsing-context name, then a different page loads into that same context and reads or replaces the value before the application clears it.

Impact: Cross-origin data exposure, broken trust boundaries, and easier attacker recovery of state that was assumed to be temporary or isolated.

Practitioner Guidance

Why practitioners should care: Review any use of window.name as you would other client-side state that can survive navigation. If the value influences routing, targeting, or state handoff, make sure the content is not sensitive and does not rely on origin-based isolation.

What to watch for: The red flag is any code that stores identifiers, tokens, redirect information, or user-specific context in the property. If the value is needed only briefly, clear it as soon as the intended handoff is complete and avoid treating it like a secure container.

Related resources from NHI Mgmt Group

• Credential reuse window
• Token Trust Window
• Offboarding Revocation Window
• Discovery-to-Exploitation Window