Proposal: Control over document.domain

[mikewest]

A Problem

document.domain is an unfortunate API that allows developers to relax the same-origin policy to enable direct access between two documents with identical registrable domains, even when their origins don't match.

Among the security issues it directly and intentionally enables, this API also makes it difficult for browser vendors to implement origin-based process isolation (as opposed to site-based isolation), as it's impossible to know a priori whether or not the origin boundary will actually be respected.

A Proposal

We should add a feature to feature policy which causes the document.domain setter to throw (as @annevk noted in #23, we shouldn't forbid access to the document.domain getter). We can initially enable this feature by default, and ratchet it down over time as we're able to drive usage down. This model seems like it'll be successful for sync XHR, and I hope it'll be applicable here as well.

That is, in the presence of:

Feature-Policy: document-domain 'none'

The following code will throw a SecurityError:

document.domain = anythingAtAll;

[mikewest]

/cc whatwg/security, @clelland. WDYT?

[clelland]

I really like this, and throwing is probably the right thing to do, rather than letting script continue on the page blindly. That does mean that it will be possible to induce an exception in a frame by turning off the feature when it is embedded.

(If we don't throw an exception here, then the site will almost certainly encounter one when it tries to access the other frame's contentDocument any way. Throwing here more clearly tells developers that setting domain is the behaviour which has been disabled)

[annevk]

This can be closed I suppose, though maybe there should be a central registry of names?

[clelland]

That sentiment is coming up more and more often. It's probably something we should start.
Anyway, yes -- closing this issue, now that the HTML change is merged.

[DavidBruant]

I'm arriving a bit late to the party, but there is already a mechanism that disables the document.domain setter in sandboxed iframes

https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Aug/0023.html
https://bugs.chromium.org/p/chromium/issues/detail?id=277084
https://bugzilla.mozilla.org/show_bug.cgi?id=907892

Does the feature discussed here add something that the sandbox attribute does not already cover?

[clelland]

It's in the HTML spec, too -- just above the FP mechansism: https://html.spec.whatwg.org/#dom-document-domain

Disabling the setter for sandboxed frames was, I think, the first thing that could reasonably be done; this extends that by allowing it for potentially any frame, sandboxed or not.

Having the feature available in feature policy also means that you will also be able to declare it as the policy for an entire origin with Origin Policy eventually, and we'll be able to do complete process isolation of an entire origin, without needing to sandbox each frame.