Document: domain property
Deprecated: This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see thecompatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.
Thedomain property of theDocumentinterface gets/sets the domain portion of theorigin of the currentdocument, as used by thesame-origin policy.
In this article
Value
A string.
Exceptions
SecurityErrorDOMExceptionThe document is forbidden from setting its domain, for example it is sandboxed or has an opaque origin. SeeFailures section for details.
Examples
>Getting the domain
For code running at the URLhttps://developer.mozilla.org/en-US/docs/Web,this example would setcurrentDomain to the string"developer.mozilla.org".
const currentDomain = document.domain;The getter for this property returns the domain portion of the current document'sorigin. In most cases, this will be the hostname portion of the document's URL. However,there are some exceptions:
- If the page has an opaqueorigin, e.g., for a page with adata URL, then it willreturn the empty string.
- If the
document.domainsetter has been used, thenit will return the value that was set.
Although the getter is not dangerous in the same way that the setter is, it is likelysimpler and more useful to use theLocation.hostname property instead.Then you can avoiddocument.domain entirely:
const currentHostname = location.hostname;For the URLhttps://developer.mozilla.org/en-US/docs/Web,currentHostname is also the string"developer.mozilla.org".Other alternatives that provide slightly different information areLocation.host, which includes the port, andWindow.origin, which provides the full origin.
Setting the domain
document.domain = domainString;The setter for this property can be used tochange a page'sorigin, and thus modify how certain security checks are performed. Itcan only be set to the same or a parent domain. For example, ifhttps://a.example.com andhttps://b.example.com both use
document.domain = "example.com";then they have both modified their origin to have the same domain, and they can nowaccess each other's DOM directly—despite being cross-origin, which would normallyprevent such access.
Note that settingdocument.domain to its current value is not a no-op. Itstill changes the origin. For example, if one page sets
document.domain = document.domain;then it will be counted as cross-origin from any other normally-same-origin pages thathave not done the same thing.
Deprecation
Thedocument.domain setter is deprecated. It undermines the securityprotections provided by thesame origin policy, and complicates the origin model in browsers, leading tointeroperability problems and security bugs.
Attempting to setdocument.domain is dangerous. It opens up full access toa page's DOM fromall subdomains, which is likely not what is intended. Italso removes the port component from the origin, so now your page can be accessed byother pages with the same IP address or same host component, even on a different port.
This is especially insecure on shared hosting. For example, another shared hostingcustomer is able to host a site at the same IP address but on a different port, thensettingdocument.domain will remove the same-origin protection thatnormally protects you from that other customer's site accessing your site's data.
Similar problems occur with shared hosting sites that give each customer a differentsubdomain. If a site setsdocument.domain, any other customer on adifferent subdomain can now do the same thing, and start accessing the data of theoriginal site.
Instead of usingdocument.domain to facilitate cross-origin communication,you should useWindow.postMessage to send an asynchronous message to theother origin. This controlled access via message-passing is much more secure than theblanket exposure of all data caused bydocument.domain.
Failures
The setter will throw aSecurityErrorDOMException inseveral cases:
- The document is inside a sandboxed
<iframe>. - The document has nobrowsing context.
- The document'seffective domain is
null. - The given value is neither the same as the page's current hostname, nor a parentdomain of it.
As an example of this last failure case, trying to setdocument.domain to"example.org" when onhttps://example.com/ will throw.
Additionally, as part of its deprecation, it will do nothing when combined with certainmodern isolation features:
- If used on a cross-origin isolated page, i.e., one that uses the appropriate valuesfor the
Cross-Origin-Opener-PolicyandCross-Origin-Embedder-PolicyHTTP headers - If used on an origin-isolated page, i.e., one that uses the
Origin-Agent-ClusterExperimental HTTP header
Finally, settingdocument.domain does not change the origin used fororigin-checks by some Web APIs, preventing sub-domain access via this mechanism.Affected APIs include (but are not limited to):Window.localStorage,IndexDB API,BroadcastChannel,SharedWorker.
Specifications
| Specification |
|---|
| HTML> # relaxing-the-same-origin-restriction> |