The `document.domain` setter allows developers to relax the same-origin policy, complicating the fundamental security boundary we aim to maintain, and putting roadblocks in the way of post-Spectre changes to Chromium's process model. We should deprecate it, first by making it opt-in via `Feature-Policy`, then by restricting it to a reverse origin trial (and/or enterprise policy), then by removing it entirely.

Motivation

Chromium's threat model (https://chromium.googlesource.com/chromium/src/+/master/docs/security/side-channel-threat-model.md) requires us to consider a process as the only defensible security boundary. To that end, aligning origins with processes is paramount. The `document.domain` setter makes this a difficult task, as we don't know whether the same-origin policy will be relaxed until runtime, when it's too late to change the process into which a document has committed. We have some opt-out mechanisms; ideally this would switch to an opt-in.

Status in Chromium

Blink>SecurityFeature


No active development (tracking bug)

Consensus & Standardization

After a feature ships in Chrome, the values listed here are not guaranteed to be up to date.

  • No signal
  • No signal
  • No signal
  • No signals

Owner

Last updated on 2020-12-08