Ticket #127: restrict-referrer-leakage.txt

Proposed Content-Security-Policy directive: "restrict-referrer-leakage"

Specification text for https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html :

3.4.2 SecurityPolicy

[add to SecurityPolicy IDL interface keeping methods in alphabetical order]

    bool allowsReferrerLeakageTo (DOMString url);

3.4.2.2 Methods

[insert keeping method descriptions in alphabetical order]

    allowsReferrerLeakageTo
        Returns the logical and of whether the provided url _matches_ the _allowed referrer recipients_
        of each of the _active CSP policies_.

         Parameter    Type          Nullable    Optional    Description
         url          DOMString        x           x

        No exceptions.
        Return type: bool

        Note: the name 'allowsReferrerLeakageTo' does not have the same spelling error as the Referer
        HTTP header [HTTP11].

[insert section before current 4.15 report-uri]

4.15 restrict-referrer-leakage (Experimental)

The restrict-referrer-leakage directive restricts which URIs may receive HTTP Referer (sic)
[HTTP11] headers, or equivalent for other protocols, containing the URI of resources to which
the policy applies.

    directive-name    = "restrict-referrer-leakage"
    directive-value   = source-list

The term *allowed referrer recipients* refers to the result of _parsing the restrict-referrer-leakage
directive's value as a source list_ if the policy contains an explicit restrict-referrer-leakage, or
otherwise to the _default sources_.

When a user agent is to _fetch a resource or URL_ as described in [HTML5] section 2.7.2 Processing model
(including as part of a _preflight request_ [CORS], _cross-origin request_ [CORS], _XMLHttpRequest_ [XHR],
etc.) then the fetch is a *no-referrer fetch* if:

  - the referrer at the "clean referrer" step of that algorithm is a _Document_ or _URL_ to which
    this policy applies; and
  - the URI to be fetched does not match the _allowed referrer recipients_.

In any no-referrer fetch, at the "clean referrer" step of the fetch algorithm, the referrer MUST
be replaced with the empty string. The effect is to ensure that the HTTP Referer header (or equivalent
for other protocols) is omitted, regardless of the value it would have but for this policy.

Any no-referrer fetch MUST be treated as a request from a "privacy-sensitive" context. [ORIGIN]

If a _Document_ is created from a no-referrer fetch, its _referrer attribute_ SHALL be the empty
string.

Whenever a new _auxiliary browsing context_ [HTML5] is created, if its opener browsing context
would be a context to which this policy applies, the getter of the opener IDL attribute on the
Window object of the new context SHALL return null (instead of the WindowProxy for the opener
browsing context that it would otherwise return).

Implementors of user agents are encouraged to look for other situations, including any resulting
from implementation-dependent features, that might result in leakage of URIs, and restrict such
leakage in a way consistent with the applicable restrict-referrer-leakage policy. This includes
leakage to contexts that are not clearly associated with an URI that can be matched against the
allowed referrer recipients, unless the applicable policy allows transmission of the referrer to
all URIs.

Note:
    The name restrict-referrer-leakage does not have the same spelling error as the Referer header.

Note:
    This specification should not be interpreted as preventing user agents from applying other
    restrictions to limit referrer leakage. 

Non-normative note:
    In particular, a user agent that never sends the HTTP Referer header (or equivalent for other
    protocols), for which a Document's referrer attribute is always the empty string, and for
    which a Window's opener attribute is always null, would not be violating either the letter
    or the intent of this specification. This would also be consistent with [HTTP11] (which has
    no normative requirement to send the Referer header, and suggests in its Security Considerations
    section to provide a convenient interface for users to disable sending it), and [HTML5] (which
    also allows user agents to be configured not to report referrers).

Non-normative note:
    The effect of this directive with an empty set of allowed referrer recipients includes the
    effect of treating all links from the affected documents as having the _noreferrer link type_
    [HTML5]. However, this directive:
      - applies to all requests, rather than only to requests made as a result of following links
        defined by an HTML 'a' or 'area' element;
      - does not require rewriting links to have the noreferrer type;
      - enables the set of allowed referrer recipients to be controlled, subject to any other
        user-agent-dependent restrictions as mentioned above;
      - is resistant to content injection attacks (at least in the case where the
        Content-Security-Policy is specified by HTTP header).