Making document.domain immutable
Web developers who rely on a workaround that relaxed the same origin policy to allow subdomains to exchange content will soon need to take a different approach.
Starting with the upcoming Chrome 106 release, Google’s web browser will close a loophole that went against best practices as well as, more importantly, posing a danger in hosted environments.
More specifically, starting from Chrome 106, websites will be unable to set ‘document.domain’, a technique that allows same-site-but-cross-origin communications.
Read more of the latest news about browser security
The current mainstream release of Google’s browser – Chrome 100 – already throws up a warning about the soon-to-be deprecated facility that allows website developers to take advantage of document.domain to relax the same-origin policy.
Website developers are urged to scan their website to access the potential impact of the deprecation of document.domain before swamping out instances where the ‘hack’ has been applied for a more secure method of cross-origin communication, as explained in a recent blog post by Google.
“On Chrome, websites will be unable to set document.domain. You will need to use alternative approaches, such as postMessage() or the Channel Messaging API, to communicate cross-origin,” Google explains.
“If your website relies on same-origin policy relaxation via document.domain to function correctly, the site will need to send an Origin-Agent-Cluster: ?0 header, as will all other documents that require that behavior.”
These alternative techniques have existed for some years. However in reality, few developers rely on document.domain to relax the same-origin policy.
Disavowed
Google is effectively killing a feature that is not widely used and is gaining a huge security benefit as a result.
The development switches the browser security paradigm from site isolation to origin isolation – drastically reducing the utility of Spectre-style attacks in the process.
Google and other browser makers are laying the groundwork for preventing attackers from pivoting between subdomains using Spectre-style attacks.
The same-origin policy offers assurances that any web page cannot access (modify, or extract data from) another page, unless those pages are hosted on the same origin.
The use of document.domain by web devs runs contrary to this rubric and poses a particular threat in the context of Spectre-style attacks, as a Github post by Google Chrome security developer Mike West illustrates.
Host of problems
Websites set document.domain in order to allow same-site documents to communicate more easily. Whilst offering convenience benefits, the approach introduces a security risk, as Google explains:
If a hosting service provides different subdomains per user, an attacker can set document.domain to pretend they are the same-origin as another user’s page.
Further, an attacker can host a website under a shared hosting service, which serves sites through the same IP address with different port numbers.
In that case, the attacker can pretend to be on the same-site-but-same-origin as yours. This is possible because document.domain ignores the port number part of the domain.
Other browser makers, including Mozilla, are also looking to deprecate document.domain.
RELATED Spectre attacks against websites still a serious threat, Google warns
