Canary patterns for window.name: tracking an overlooked DOM XSS source

window.name is one of the more obscure DOM sources, and its obscurity is exactly what makes it interesting to an attacker. The property persists across navigations inside the same browsing context, which means attacker-controlled content can survive a redirect into a target application and reach script on the other side. This post explains the persistence quirk that makes window.name dangerous and the canary pattern Pentrova uses to track it.

It sits inside the broader DOM XSS taint tracking technique; this article zooms in on the one source that catches the most teams off guard.

The persistence quirk#

Most DOM sources are scoped to the current page: location.hash, location.search, and document.referrer all reset on navigation. window.name does not. Whatever a page writes to window.name stays readable after the browsing context navigates to a completely different origin.

That is by design — window.name predates modern cross-window messaging and was used as a convenience channel for passing data between windows. The side effect is a cross-origin-survivable, attacker-writable string that the destination page can read:

1. attacker page sets:   window.name = "pv_a9f3_windowname_<payload>"
2. navigates the tab to: https://target.example/app
3. target's JS reads:    window.name   ← attacker-controlled value survives

Why it looks innocuous in code review#

A few production frameworks still read window.name as a convenience for cross-window messaging during migration from older APIs. The pattern looks harmless in review because the value is “only” a window name — but the browser does not distinguish between a scan payload and a legitimate name. If that value reaches a sink like innerHTML or eval, it is DOM-based XSS (CWE-79), no different from any other tainted source in the OWASP DOM XSS prevention guidance.

The canary pattern#

The technique is straightforward. Pentrova’s DOM XSS module plants a channel-tagged canary in window.name before sending the target a navigation primitive. The canary wrapper (for example pv_a9f3_windowname_) identifies both the channel and the run, so any sink hit can be attributed back to window.name specifically rather than to some other source.

If the target application reads from window.name and routes the value into one of the tracked sinks, the canary evaluates and the platform captures the exact chain: the source read, the intermediate transformations, and the final sink write. That path is the proof — captured as deterministic evidence, reproduced under sandbox guardrails as part of every Web App Pentesting engagement.

Remediation#

The fix is to treat window.name as untrusted input wherever it is read:

• Never pass window.name into a DOM sink (innerHTML, eval, document.write, setAttribute for event handlers).
• Migrate legacy cross-window data passing to postMessage with strict origin checks.
• Apply a Content Security Policy as defence in depth so an injected script has fewer places to execute.

Key takeaways#

• window.name survives cross-origin navigation, making it an attacker-writable source the destination page reads.
• It looks harmless in code review precisely because it is “just a name”.
• A channel-tagged canary planted before navigation attributes any sink hit back to window.name.
• Treat it as untrusted input and migrate to origin-checked postMessage.

FAQ#

Why is window.name more dangerous than other DOM sources? Because it persists across navigations and origins. An attacker can set it on their own page, navigate the tab to your application, and your script reads the attacker’s value — something location.hash or referrer cannot do as cleanly.

How do I know if my app reads window.name? Grep your bundle for window.name reads, and trace where the value flows. Pentrova automates this by planting a canary and watching whether it reaches a sink, which catches reads buried inside framework or third-party code.

Does CSP stop window.name XSS? A strict CSP raises the bar by limiting where injected script can execute, but it is defence in depth — the real fix is to stop routing window.name into dangerous sinks. Check your headers with the security header scanner.

Read the full DOM XSS taint technique, or start a free engagement.