Content Security Policy: Embedded Enforcement

1. Introduction

This section is not normative.

Content Security Policy is a great defense against cross-site scripting attacks, allowing developers to harden their own sites against injection of malicious script, style, and other resource types. It does not, however, give developers the ability to apply restrictions to third-party content loaded in via <iframe>. Allowing CSP to apply directly to these third-party contexts would be dangerous; CSP gives quite granular control over resource loading, and it’s very possible to introduce vulnerabilities into an otherwise secure page by denying it access to particular scripts. We’ve seen these kinds of issues in past features such as X-XSS-Protection, so we must be careful to avoid reintroducing them in a new form.

That said, it would be quite useful to be able to place restrictions upon widgets, advertisements, and other kinds of third-party content. This document proposes a mechanism which relies on an explicit opt-in from the embedded content, which ought to make it possible for widgets to cooperate with their embedders to negotiate a reasonable set of restrictions.

In short, the embedder proposes a Content Security Policy as an attribute on the <iframe> element. This policy is transmitted along with the HTTP request for the framed content in an Embedding-CSP header. If the embedded content can accept that policy, it may do so by returning the proposed policy in a Content-Security-Policy header along with the response.

If the response contains a policy identical to the policy which the embedder requested, the user agent will render the embedded content. If no such policy is present, the response will be blocked.

1.1. Examples

<iframe src="https://advertisements-r-us.example.com/ad1.cfm"
        csp="script-src https://trusted-cdn.example.com/">
</iframe>

GET / HTTP/1.1
Host: advertisements-r-us.example.com
...
Embedding-CSP: script-src https://trusted-cdn.example.com/
...

HTTP/1.1 200 OK
...
Content-Security-Policy: script-src https://trusted-cdn.example.com/

HTTP/1.1 200 OK
...
Content-Security-Policy: script-src https://trusted-cdn.example.com/,
                         object-src 'none'

2. Framework

2.1. Specifying a Policy Requirement

Monkey-patching HTML.

Browsing contexts have an iframe security policy attribute, which is null unless otherwise specified.

iframe elements have a csp attribute which specifies the policy that an embedded document must agree to enforce upon itself.

partial interface HTMLIFrameElement {
  attribute DOMString csp;
};

HTMLIFrameElement's csp IDL attribute reflects the value of the element’s csp content attribute.

When an iframe element with a csp attribute has its nested browsing context created (before the intial about:blank Document is created), and when an iframe element’s csp attribute is set or changed while it has a nested browsing context, the user agent must set the nested browsing context’s iframe security policy to the result of executing the parse a serialized policy algorithm on the csp attribute’s value.

During the navigate algorithm, perform the following step after the current step 19. At this point, the user agent has fetched a response which it is about to begin parsing, and redirects have been processed:

20. If the algorithm in §3.1 Is response blocked by context’s iframe security policy? returns Blocked when executed upon the resource and the browsing context being navigated, abort these steps. The user agent MAY indicate to the user that navigation has been aborted for security reasons.

2.2. The Embedding-CSP HTTP Request Header

In order to ensure that the embedded resource can decide whether or not it is willing to adhere to the embedder’s requirements, the policy expressed in an iframe's csp attribute is communicated along with some requests via an "Embedding-CSP" HTTP request header. The header’s value is represented by the following ABNF [RFC5234]:

Embedding-CSP = serialized-policy

A user agent MUST NOT send more than one HTTP response header field named "Embedding-CSP", and any such header MUST NOT contain more than one serialized-policy.

Step ~15 of the navigate algorithm needs to be adjusted to add an Embedding-CSP header to a navigational request iff the navigation targets a nested browsing context, and if the browsing context container is an iframe element with a csp attribute. This should be pretty straightforward once the algorithm is rewritten in terms of Fetch, but is a bit tricky today.

3. Algorithms

3.1. Is response blocked by context’s iframe security policy?

Given a response (response) and a browsing context (context), this algorithm returns Allowed or Blocked as appropriate:

1. Let embedding policy be the value of context’s iframe security policy.

2. Let policy list be the value of response’s CSP list.

3. If the §3.2 Is policy list subsumed under subsuming policy? algorithm returns Subsumed when executed upon policy list and embedding policy, return Allowed.

4. Return Blocked.

3.2. Is policy list subsumed under subsuming policy?

Given a list of policy objects (policy list), this algorithm returns Subsumed if that list enforces a policy which is an exact match for a given policy object (subsuming policy). It returns Not Subsumed otherwise.

Note: Ideally, we’ll someday define a real subsumption algorithm which would verify that the policy default-src 'none'; script-src https://example.com is subsumbed under default-src *.example.com (as there is no case in which the latter will block a request that the former would allow). That calculation turns out to be hard, so the current algorithm takes the significantly simpler approach of requiring an exact match.

Note: This is not an efficient algorithm. Implementers are encouraged to implement something a little smarter and faster, with the same behavior.

1. If subsuming policy is null, return Subsumed.

2. For each policy in policy list:

   1. If policy’s disposition is not Enforce, set skip to the next policy.

   2. If policy’s directive set is not the same size as subsuming policy’s directive set, skip to the next policy.

   3. For each directive in policy’s directive set:

      1. Let subsuming directive be the directive in subsuming policy’s directive set whose name matches directive’s name, or null if no such directive is present.

      2. If subsuming directive is null, skip to the next policy.

      3. If subsuming directive’s value list is not the same size as directive’s value list, skip to the next policy.

      4. For each token in directive’s value:

         1. If token is not present in subsuming directive’s value, skip to the next policy.

   4. Return Subsumed.

3. Return Not Subsumed.

4. Security Considerations

Embedded documents should be careful to evaluate the proposed Content Security Policy, and not simply to reflect whatever policy an embedder suggests. Doing so may enable a clever attacker to selectively disable pieces of a website’s code which are essential for its own protection.

In particular, documents which do not expect to be embedded should continue to respond to any such request with a Content Security Policy containing an appropriate frame-ancestors directive.

5. Privacy Considerations

This feature allows an embedder to send information to a third-party endpoint via the Embedding-CSP HTTP header. This doesn’t seem to expose any information that couldn’t be tunneled in the HTTP request itself (via GET parameters, etc), and embedders remain in control over the endpoints to which such requests may be made by enforcing a Content Security Policy with an appropriate child-src directive.

6. IANA Considerations

The permanent message header field registry should be updated with the following registration: [RFC3864]

6.1. Embedding-CSP

Header field name

Embedding-CSP

Applicable protocol

http

Status

standard

Author/Change controller

W3C

Specification document

This specification (See §2.2 The Embedding-CSP HTTP Request Header)