firstDaisy Diff compare report.
Click on the changed parts for a detailed description. Use the left and right arrow keys to walk through the modifications.
last 

This document defines a policy language used to declare a set of content restrictions for a web resource, and a mechanism for transmitting the policy from a server to a client where the policy is enforced.

Introduction

The purpose of this specification is to provide a method for web applications to broadly address a large class of vulnerabilities known as content injection which is the primary focus of Content Security Policy. Other threatsThis document defines Content Security Policy, a mechanism web applications can use to mitigate the broad class of content injection vulnerabilities, such as cross-site request forgery, are not a focus of this specificationscripting (XSS). Content Security Policy is a declarative policy framework that enables web authors and server administrators to specify the permitted sources of content in their web applications and to restrict the capabilities of that content. Content Security Policy mitigates and detects content injection attacks such as cross-site scripting (XSS).

Content Security Policy is not intended to be a fool-proof security system, but it is intended to provide an effective layer of security that will dovetail with any site's existing web application security program.

Content Security Policy is an opt-in mechanism which requires that servers explicitly declare a security policy in order to receive any of the protection described in this document. Content Security Policies are applied by the user-agent on a per resource basis, so servers must emit a security policy with each resource that the server wants protected.

Conformance Criteria

This specification is written for resource authors and user-agents. All examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC 2119. [[!RFC2119]]

lets the authors (or server administrators) of a web application restrict from where the application can load resources.

To mitigate XSS, for example, a web application can restrict itself to loading scripts only from known, trusted URIs, making it difficult for an attacker who can inject content into the web application to inject malicious script.

Content Security Policy (CSP) is not intended as a first line of defense against content injection vulnerabilities. Instead, CSP is best used as defense-in-depth, to reduce the harm caused by content injection attacks.

There is often a non-trivial amount of work required to apply CSP to an existing web application. To reap the greatest benefit, authors will need to move all inline script and style out-of-line, for example into external scripts, because the user agent cannot determine whether an inline script was injected by an attacker.

To take advantage of CSP, a web application needs to opt into using CSP by supplying a Content-Security-Policy HTTP header or an appropriate HTML meta element. Such policies apply the current document only. To supply a policy for an entire site, the server need to supply a policy along with each resource representation.

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm.

A conformant user-agent is one that implements all the requirements listed in this specification that are applicable to user-agents.

A conformant server is one that implements all the requirements listed in this specification that are applicable to servers.

Terminology

This section defines several terms used throughout the document.

The term security policy, or simply policy, for the purposes of this specification refers to either:

A

  1. a set of security preferences for restricting the behavior of content within a given document, or

resourceA

  1. a fragment of text that codifies these preferences.

The security policies defined by this document are applied by a user-agent on a per-resource representation basis. Specifically, when a user agent receives a policy along with the representation of a given resource, that policy applies to that resource representation only. That resource representation is often referred to in this document as the protected document.

A server transmits

their

its security policy for a particular resource as a

composition

collection of directives, such as default-src 'self', each of which controls a specific set of

content capabilities within

privileges for a document rendered by a user-agent.

Directives may also be used to specify the locations of resources needed by user-agents to process and enforce security policies.

More details are provided in the directives section.

A directive

is composed

consists of a directive name, which indicates the

class of content that is to be restricted

privileges controlled by the

user-agent

directive, and a directive value, which specifies the

range of permitted behavior for that content class.

Most of the policy directives defined in this document take a list of sources as the directive value. A source is a location, such as a network host, from which content of a particular type can be fetched according to the fetching algorithm defined in the HTML 5 standard [[!HTML5]]. Sources can be specified according to scheme, host and port.

restrictions the policy imposes on those privileges.

Fetching resources requires resolving and parsing URLs. The algorithms for resolving a URL and parsing a URL are defined in the

HTML 5

HTML5 standard [[!HTML5]].

Content Security Policies are applied by a user-agent on a per-resource basis. This means that when a server emits a Content Security Policy in a response, the user-agent applies the stated policy to the document returned in that response only for the lifetime of the document. That document is often referred to in this specification as the protected document or protected resource.

When Content Security Policy is enabled by a server, several base restrictions are applied in the user-agent processing model. These base restrictions provide support for the primary threat model.

The term origin is

used per its definition

defined in the Origin specification. [ORIGIN]

The term URI is defined in the URI specification. [[!URI]]

The <script>, <object>, <embed>, <img>, <video>, <audio>, <link>, <frame> and <iframe> elements

and the Window object

are defined in the

HTML 5 This section defines the general framework for content security policies.

HTML5 standard. [[!HTML5]].

The <applet> element is defined in the HTML 4.01 standard. [[!HTML401]].

The @font-face CSS rule is defined in the CSS Fonts Module Level 3 standard. [[!CSS3FONT]]

The XMLHttpRequest object is defined in the XMLHttpRequest standard. [[!XMLHTTPREQUEST]]

The WebSocket object is defined in the WebSocket standard. [WEBSOCKET].

The EventSource object is defined in the EventSource standard. [EVENTSOURCE].

Framework

The

next section contains the directive introduced in this specification.

Directives

This section describes the content security policy directives introduced in this specification.

XYZZY

Syntax

This section defines the syntax and semantics of the policy directives and policy delivery mechanisms introduced by this specification.

The

Augmented Backus-Naur Form (ABNF) notation used in this document is specified in RFC 5234. [[!ABNF]]

The following core rules are included by reference, as defined in [ABNF Appendix B.1]: ALPHA (letters), DIGIT (decimal 0-9), WSP (white space) and VCHAR (printing characters).

Framework

This section defines the general framework for content security policies, including the delivery mechanisms and general syntax for policies. The next section contains the details of the specific directives introduced in this specification.

Policy Delivery

The policy can be delivered from the server to the client via an HTTP response header or an HTML meta element. Both mechanisms indicates that a resource MUST have the set of restrictions specified in the policy applied to it by the user-agent while rendering the content.

X-

Of the two delivery mechanisms, servers SHOULD use the HTTP response header mechanism whenever possible because, when using the meta element mechanism, there is a period of time between when the user agent begins to process the document and when the user agent encounters the meta element when the document is not protected by the policy.

Content-Security-Policy Response Header

The policy is transmitted as the HTTP header value and is parsed by the client before it receives the response body.

The syntax of the HTTP header will be defined in a future specification of the IETF Web Security Working Group. This document assumes a header structure as defined by the following simple ABNF:

content-security-policy = "X-Content-Security-Policy:" OWS [ policy ] OWS OWS

Field

The Content-Security-Policy header field is the preferred mechanism for delivering a CSP policy.

A server MAY supply one or more CSP policies in HTTP response header fields named Content-Security-Policy along with the protected document.

Upon receiving an HTTP response containing at least one Content-Security-Policy header field, the user agent MUST enforce the combination of all the policies contained in these header fields.

Content-Security-Policy-Report-Only Header Field

The Content-Security-Policy-Report-Only header field lets server experiment with CSP by monitoring (rather than enforcing) a policy. This feature lets server operators develop their security policy iteratively. They can deploy a report-only policy based on their best estimate of how their site behaves. If their site violates this policy, instead of breaking the site, the user agent will send violation reports to a URI specified in the policy. Once a site has confidence that the policy is appropriate, they can promote the report-only policy to normal blocking mode.

A server MAY supply one or more CSP policies in HTTP response header fields named Content-Security-Policy-Report-Only along with the protected document.

If a server supplies at least one Content-Security-Policy-Report-Only header field in an HTTP response, the server MUST NOT supply any Content-Security-Policy header fields.

Upon receiving an HTTP response containing at least one Content-Security-Policy-Report-Only header field, the user agent MUST monitor the combination of all the policies contained in these header fields.

HTML meta Element

The server MAY supply a CSP policy in an HTML meta element with an http-equiv attribute that is a case insensitive match for either Content-Security-Policy or Content-Security-Policy-Report-Only.

Add the following entries to the pragma directives for the meta element:

Content security policy (http-equiv="content-security-policy")
  1. If the document already has a csp-policy, abort these steps.
  2. If the meta element lacks a content attribute, abort these steps.
  3. Enforce the CSP policy contained in the content attribute of the meta element.
Content security policy, report only (http-equiv="content-security-policy-report-only")
  1. If the document already has a csp-policy, abort these steps.
  2. If the meta element lacks a content attribute, abort these steps.
  3. Monitor the CSP policy contained in the content attribute of the meta element.

Syntax

Policies

A CSP policy consists of a U+003B SEMICOLON (;) delimited list of directives:


policy            = directive-list
directive-list    = [ directive *( ";" [ directive ] ) ]

Each directive consists of a directive-name and (optionally) a directive-value:


directive         = *WSP [ directive-name [ WSP directive-value ] ]
directive-name    = 1*( [ALPHA CRLF/ ]DIGIT WSP/ "-" )
; "optional white space"

where <policy> is a sequence of directives defined later in this document. The preceding definition includes by reference the core rules CRLF and WSP, as defined in [ABNF Appendix B.1]

Content Security Policy can be deployed in report-only mode by sending the HTTP response header X-Content-Security-Policy-Report-Only.

<meta http-equiv="X-Content-Security-Policy"> HTML Element

The policy is transmitted as the content attribute of the element.

The Content Security Policy element MUST be placed in the <head> element of the document and MUST precede all other <meta> elements in order to be treated as valid policy.

There probably need to be additional restrictions placed on what other elements cannot precede the policy element due to their parsing causing side effects that the policy won't have an opportunity to prevent.

Content Security Policy can be deployed in report-only mode by placing a <meta http-equiv="X-Content-Security-Policy-Report-Only"> HTML element in the <head> section of a document.

The semantics of the <meta> and <head> elements are defined in the HTML 5 standard. [[!HTML5]]

Delivery Mechanism Precedence

Policies expressed in X-Content-Security-Policy response headers take precedence over policies expressed via meta elements. If no X-Content-Security-Policy response headers are present, then the first Content Security Policy meta element found in the document head takes precedence.

Directives

This section describes the policy directives introduced by this specification.

None of the policy directives listed below are required for a policy to be treated as valid, though user-agents SHOULD consider a policy containing no recognized directives as a processing error and SHOULD report a warning message to the error console communicating that a policy containing no recognized directives was received.

default-src

The default-src directive defines the default policy for all types of content which are not explicitly restricted by any of the other directives specified in a policy. The directive value represents the default list of sources from which content of types not specified elsewhere in the policy may be fetched.

An exception to the default-src directive value being used as the default policy exists in the case of the frame-ancestors directive, which MUST be enforced as * (all sources) when not explicitly declared.

User-agents MUST enforce the default-src directive for any content request which would be restricted by one of the following more specific directives when that specific directive is not present in the policy
directive-value   = *( WSP / <VCHAR except ";"> )

To parse a CSP policy policy, the user agent MUST use an algorithm equivalent to the following:

  1. Let the set of directives be the empty set.
  2. For each token returned by strictly splitting the string policy on the character U+003B SEMICOLON (;):
    1. Skip whitespace.
    2. Collect a sequence of characters that are not space characters. The collected characters are the directive name.
    3. If position doesn't point past the end of the token, skip ahead one character (which must be a space character).
    4. The remaining characters in token (if any) are the directive value.
    5. If the set of directives already contains a directive with name directive name, ignore this instance of the directive and continue to the next token.
    6. Add a directive to the set of directives with name directive name and value directive value.
  3. Return the set of directives.

Source List

Many CSP directives use a value consisting of a source list.

Each source expression in the source list represents a location from which content of the specified type can be retrieved. For example, the source expression 'self' represents the set of URIs which are in the same origin as the protected document and the source expression 'unsafe-inline' represents content supplied inline in the document itself.


source-list       = *WSP [ source-expression *( 1*WSP source-expression ) *WSP ]
                  / *WSP "'none'" *WSP
source-expression = scheme-source / host-source / keyword-source
scheme-source     = scheme ":"
host-source       = ( [ scheme "://" ] host [ port ] )
keyword-source    = "'self'" / "'unsafe-inline'" / "'unsafe-eval'"
scheme            = <scheme> production from RFC 3986
host              = "*" / [ "*." ] 1*host-char *( "." 1*host-char )
host-char         = ALPHA / DIGIT / "-"
port              = ":" ( 1*DIGIT / "*" )

To parse a source list source list, the user agent MUST use an algorithm equivalent to the following:

  1. If source list (with leading and trailing whitespace stripped) is a case insensitive match for the string 'none' (including the quotation marks), return the empty set.
  2. Let the set of source expressions be the empty set.
  3. For each token returned by splitting source list on spaces, if the token matches the grammar for source-expression, add the token to the set of source expressions.
  4. Return the set of source expressions.

To check whether a URI matches a source expression, the user agent MUST use an algorithm equivalent to the following:

  1. If the source expression a single U+002A ASTERISK character (*), then return does match.
  2. If the source expression matches the grammar for scheme-source, then the URI matches the source expression of the URI's scheme is a case-insensitive match for the source expression's scheme.
  3. Otherwise, if the source expression matches the grammar for host-source:
    1. If the URI does not contain a host, then return does not match.
    2. Let scheme, host, and port be the scheme, host, and port of the URI, respectively. If the URI does not have a port, then let port be the default port for scheme.
    3. If the source expression has a scheme that is not a case insensitive match for scheme, then return does not match.
    4. If scheme is not a case insensitive match for the scheme of the protected document's URI, then return does not match.
      FIXME: Should we allow HTTPS when the document's scheme is HTTP?
    5. If the first character of the source expression's host is an U+002A ASTERISK character (*) and the remaining characters, including the leading U+002E FULL STOP character (.), are not a case insensitive match for the rightmost characters of host, then return does not match.
    6. If host is not a case insensitive match for the source expression's host, then return does not match.
    7. If the source expression does not contain a port and port is not the default port for scheme, then return does not match.
    8. If the source expression does contain a port that (a) does not contain an U+002A ASTERISK character (*) and (b) does not represent the same number as port, then return does not match.
    9. Return does match.
  4. Otherwise, if the source expression is a case insensitive match for 'self' (including the quotation marks), then return the URI matches the source expression if the URI has the same scheme, host, and port as the document's URI.
  5. Otherwise, the URI does not match the source expression.

A URI matches a source list, if, and only if, the URI matches at least one source expression in the set of source expressions obtained by parsing the source list. Notice that no URIs match an empty set of source expressions, such as the set obtained by parsing the source list 'none'.

Processing Model

To enforce a CSP policy, the user agent MUST parse the policy and enforce each of the directives contained in the policy, where the specific requirements for enforcing each directive are defined separately for each directive (See Directives, below).

Generally speaking, enforcing a directive prevent the protected document from performing certain actions, such as loading scripts from URIs other than those indicated in a source list. These restrictions make it more difficult for an attacker to abuse an injection vulnerability in the document because the attacker will be unable to usurp the document's privileges that have been restricted in this way.

Enforcing a CSP policy SHOULD NOT interfere with the operation of user-supplied scripts such as third-party user-agent add-ons and JavaScript bookmarklets.

To monitor a CSP policy, the user agent MUST parse the policy and monitor each of the directives contained in the policy, where the specific requirements for monitoring each directive are defined separately for each directive (See Directives, below).

Generally speaking, monitoring a directive does not prevent the protected document from undertaking any actions. Instead, any actions that would have been prevented by the directive are instead reported to the developer of the web application. Monitoring a CSP policy is most useful for testing whether enforcing the policy will break the web application.

If the user agent monitors or enforces a CSP policy that does not contain any directives, the user agent SHOULD report a warning message in the developer console.

If the user agent monitors or enforces a CSP policy that contains an unrecognized directive, the user agent SHOULD report a warning message in the developer console indicating the name of the unrecognized directive.

To enforce the combination of one or more policies, the user agent MUST enforce each policy. For example, if an action is prevented by at least one of the policies, then the action will be prevented by the combination of the policies.

To monitor the combination of one or more policies, the user agent MUST monitor each each policy.

Directives

This section describes the content security policy directives introduced in this specification.

In order to protect against Cross-site Scripting (XSS), authors SHOULD include

In either case, authors SHOULD NOT include 'unsafe-inline' in their CSP policies if they wish to protect themselves against XSS.

default-src

The default-src directive sets a default source list for a number of directives. The syntax for the name and value of the directive are described by the following ABNF grammar:


directive-name    = "default-src"
directive-value   = source-list

Let the default sources be the result of parsing the directive's value as a source list.

To enforce the default-src directive, the user agent MUST enforce the following directives:

If not specified explicitly in the policy, the directives listed above will use the default sources.

script-src

The script-src directive

defines the list of sources from which script resources may be fetched as external <script> elements or Worker objects in HTML documents or <?xml-stylesheet?> processing instructions in XML documents.

Prior to a script resource being fetched, the script resource URL MUST first be validated as conforming to the protected document's script-src directive.

Script resource URLs requiring validation prior to fetching include:

  1. src attributes on <script> elements within HTML documents
  2. scriptURL arguments passed to the the Worker and SharedWorker constructors within HTML documents
  3. href attributes on <xsl:include> elements within XML documents
  4. href attributes on <xsl:import> elements within XML documents

Any script resource URLs identified per the above MUST first be resolved relative to the containing element and then parsed into its component parts. The resulting scheme, host and port tuple MUST be present in the source list defined by the script-src directive in order for the script resource to be requested.

User-agents MUST NOT request script resources from non-approved sources.

In the case of an XSL transformation, any content to be included into the resulting XML document must conform to the original XML document's security policy prior to being fetched or loaded.

If the script-src directive is not present in a policy and the default-src directive is present in the policy, user-agents MUST subject requests for script resources to the default-src directive.

object-src

The object-src directive defines the list of sources from which external resources may be fetched when constructing <object>, <embed> and <applet> elements.

Prior to fetching any external resource required by an <object>, <embed> or <applet> element, the resource URL MUST first be validated as conforming to the protected document's object-src directive.

Resource URLs requiring validation prior to fetching include:

  1. data attributes on <object> elements
  2. src attributes on <embed> elements
  3. code or archive attributes on <applet> elements

Resource URLs contained in the <applet> element attributes listed above may be specified relative to the element's codebase attribute or relative to the containing document's base URL.

Any <object>, <embed> or <applet> resource URLs identified per the above MUST first be resolved relative to the containing element and then parsed into its component parts. The resulting scheme, host and port tuple MUST be present in the source list defined by the object-src directive in order for the resource URL to be requested.

User-agents MUST NOT request <object>, <embed> or <applet> resource URLs from non-approved sources.

If the object-src directive is not present in a policy and the default-src directive is present in the policy, user-agents MUST subject requests for <object>, <embed> and <applet> resources to the default-src directive.

In order to achieve comprehensive XSS protection, sites must include both a script-src directive and an object-src directive in their policy, or a default-src directive, which covers both cases, due to some plugins having scripting capability.

Some plugins, e.g. Google Gears, do not load via URLs. How does object-src interact with these kinds of plugins?

img-src

The img-src directive defines the list of sources from which images may be fetched via <img> elements, CSS properties and shortcut icons, a.k.a. favicons.

Prior to fetching an image resource, the image resource URL MUST first be validated as conforming to the protected document's img-src directive.

Resource URLs requiring validation prior to fetching include:
  • src attributes on <img> elements
  • restricts which scripts the protected document can execute. The directive also controls other resources, such as XSLT stylesheets, which can cause the user agent to execute script. The syntax for the name and value of the directive are described by the following ABNF grammar:

    
    directive-name    = "script-src"
    directive-value   = source-list
    
    

    If the policy contains an explicit script-src, let the allowed script sources be the result of parsing the directive's value as a source list. Otherwise, let the allowed script sources be the default sources

    If 'unsafe-inline' is not in allowed script sources:

    If 'unsafe-eval' is not in allowed script sources:

    The term callable refers to an object whose interface has one or more callers as defined in the Web IDL specification [[!WEBIDL]].

    Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed script sources, the user agent MUST act as if it had received an empty HTTP 400 response:

    object-src

    The object-src directive restricts from where the protected document can load plugins. The syntax for the name and value of the directive are described by the following ABNF grammar:

    
    directive-name    = "object-src"
    directive-value   = source-list
    
    

    If the policy contains an explicit object-src, let the allowed object sources be the result of parsing the directive's value as a source list. Otherwise, let the allowed object sources be the default sources

    Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed object sources, the user agent MUST act as if it had received an empty HTTP 400 response:

    Whenever the user agent would load a plug-in without an associated URI (e.g., because the object element lacked a data attribute), if the protected document's URI does not match the allowed object sources, the user agent MUST NOT load the plug-in.

    style-src

    The style-src directive restricts which styles the user applies to the protected document. The syntax for the name and value of the directive are described by the following ABNF grammar:

    
    directive-name    = "style-src"
    directive-value   = source-list
    
    

    If the policy contains an explicit style-src, let the allowed style sources be the result of parsing the directive's value as a source list. Otherwise, let the allowed style sources be the default sources

    If 'unsafe-inline' is not in allowed style sources:

    Note: These restrictions on inline do not prevent the user agent from applying style from an external stylesheet (e.g., found via <link rel="stylesheet">). The user agent is also not prevented from applying style from CSSOM.

    Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed style sources, the user agent MUST act as if it had received an empty HTTP 400 response:

    Note: The style-src directive does not restrict the use of XSLT. XSLT is restricted by the script-src directive because the security consequences of including an untrusted XSLT stylesheet are similar to those incurred by including an untrusted script.

    img-src

    The img-src directive restricts from where the protected document can load images. The syntax for the name and value of the directive are described by the following ABNF grammar:

    
    directive-name    = "img-src"
    directive-value   = source-list
    
    

    If the policy contains an explicit img-src, let the allowed image sources be the result of parsing the directive's value as a source list. Otherwise, let the allowed image sources be the default sources

    Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed image sources, the user agent MUST act as if it had received an empty HTTP 400 response:

  • href attributes on <link rel="icon"> or <link rel="shortcut icon"> elements
  • Any resource URLs identified per the above MUST first be resolved relative to the <img> element, <style> element or external stylesheet URL, or <link> element, as appropriate. Each resolved resource URL must then be parsed into its component parts. The resulting scheme, host and port tuple MUST be present in the source list defined by the img-src directive in order for the image resource to be requested.

    User-agents MUST NOT request image resources from non-approved sources.

    Should the user agent fire the error event when one of these loads fails?

    If the img-src directive is not present in a policy and the
    default

    media-src

    The media-src directive

    is present in the policy, user-agents MUST subject requests for image resources to the default-src directive.

    The url() and image() notations are defined in the CSS Image Values and Replaced Content Module Level 3 standard. [CSS3-Images]

    media-src

    The media-src directive defines the list of sources from which external resources may be fetched via <video> and <audio> elements.

    Prior to a <video> or <audio> resource being fetched, the URL in the element's src attribute MUST first be resolved relative to the element and then parsed into its component parts. The resulting scheme, host and port tuple MUST be present in the source list defined by the media-src directive in order for the resource to be requested.

    User-agents MUST NOT request <video> or <audio> resources from non-approved sources.

    If the media-src directive is not present in a policy and the default-src directive is present in the policy, user-agents MUST subject requests for <video> and <audio> resources to the default-src directive.

    style-src

    The style-src directive defines the list of sources from which external stylesheets may be fetched via <link rel="stylesheet"> elements.

    Prior to an external stylesheet being fetched, the URL in the href attribute of the <link rel="stylesheet"> element MUST first be resolved relative to the element and then parsed into its component parts. The resulting scheme, host and port tuple MUST be present in the source list defined by the style-src directive in order for the stylesheet to be requested.

    User-agents MUST NOT request external stylesheets from non-approved sources.

    If the style-src directive is not present in a policy and the default-src directive is present in the policy, user-agents MUST subject requests for external stylesheets to the default-src directive.

    frame-src

    The frame-src directive defines the list of sources from which resources may be fetched via <iframe> elements, and to which hosts those <iframe> elements may be navigated.

    Prior to an <iframe> resource being fetched, the URL in the <iframe> element's src attribute MUST first be resolved relative to the element and then parsed into its component parts. The resulting scheme, host and port tuple MUST be present in the source list defined by the frame-src directive in order for the resource to be requested.

    Prior to an <iframe> element being navigated, the new location MUST first be resolved relative to the element and then parsed into its component parts. The resulting scheme, host and port tuple MUST be present in the source list defined by the frame-src directive for the navigation to be permitted.

    User-agents MUST NOT request <iframe> resources from non-approved sources nor navigate <iframe> elements to non-approved sources.

    If the frame-src directive is not present in a policy and the default-src directive is present in the policy, user-agents MUST subject <iframe> requests to the default-src directive

    restricts from where the protected document can load video and audio. The syntax for the name and value of the directive are described by the following ABNF grammar:

    
    directive-name    = "media-src"
    directive-value   = source-list
    
    

    If the policy contains an explicit media-src, let the allowed media sources be the result of parsing the directive's value as a source list. Otherwise, let the allowed media sources be the default sources

    Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed media sources, the user agent MUST act as if it had received an empty HTTP 400 response:

    frame-src

    The frame-src directive restricts from where the protected document can embed frames. The syntax for the name and value of the directive are described by the following ABNF grammar:

    
    directive-name    = "frame-src"
    directive-value   = source-list
    
    

    If the policy contains an explicit frame-src, let the allowed frame sources be the result of parsing the directive's value as a source list. Otherwise, let the allowed frame sources be the default sources

    Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed frame sources, the user agent MUST act as if it had received an empty HTTP 400 response:

    How does this work for the object element? We don't know whether the request is going to lead to a plug-in or a frame until we get the response back and can look at the MIME type.

    font-src

    The font-src directive

    defines the list of sources from which downloadable fonts may be fetched using the @font-face CSS rule.

    Prior to a font resource being fetched, the url value of the src descriptor of the @font-face CSS rule MUST first be resolved relative to the <style> element or the external stylesheet URL where the @font-face CSS rule is declared. The resolved URL MUST then be parsed into its component parts. The resulting scheme, host and port tuple MUST be present in the source list defined by the font-src directive in order for the downloadable font resource to be requested.

    User-agents MUST NOT request downloadable font resources from non-approved sources.

    If the font-src directive is not present in a policy and the default-src directive is present in the policy, user-agents MUST subject requests for downloadable font resources to the default-src directive.

    restricts from where the protected document can load fonts. The syntax for the name and value of the directive are described by the following ABNF grammar:

    
    directive-name    = "font-src"
    directive-value   = source-list
    
    

    If the policy contains an explicit font-src, let the allowed font sources be the result of parsing the directive's value as a source list. Otherwise, let the allowed font sources be the default sources

    Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed font sources, the user agent MUST act as if it had received an empty HTTP 400 response:

    connect-src

    The connect-src directive

    defines the list of sources that are permitted to be connected to via the DOM APIs XMLHttpRequest, WebSocket and EventSource.

    Prior to connecting to an external source using one of the restricted APIs, the source URL MUST first be validated as conforming to the protected document's connect-src directive.

    Source URLs requiring validation prior to connection include: The url argument passed to

    restricts which URIs the protected document can load using DOM APIs. The syntax for the name and value of the directive are described by the following ABNF grammar:

    
    directive-name    = "connect-src"
    directive-value   = source-list
    
    

    If the policy contains an explicit connect-src, let the allowed connection targets be the result of parsing the directive's value as a source list. Otherwise, let the allowed connection targets be the default sources

    Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed font sources, the user agent MUST act as if it had received an empty HTTP 400 response:

    The url argument passed to The url argument passed to

    Any source URLs identified per the above MUST first be fully resolved. In the case of an XMLHttpRequest object, the source URL MUST be resolved relative to the object's base URL. In the case of an EventSource object, the source URL MUST be resolved relative to the entry script's base URL. A WebSocket URL is required to be an absolute URL, and thus does not require relative resolution. Once resolved, the source URL MUST be parsed into its component parts. The resulting scheme, host and port tuple MUST be present in the source list defined by the connect-src directive in order for the connection to be made.

    User-agents MUST NOT connect to any non-approved sources via restricted APIs.

    If the connect-src directive is not present in a policy and the default-src directive is present in the policy, user-agents MUST subject XMLHttpRequest, WebSocket and EventSource connections to the default-src directive.

    frame-ancestors

    The frame-ancestors directive defines the list of sources that are permitted to embed the protected resource as an <iframe>, <frame> or <object> element.

    If the frame-ancestors directive is present in a policy, the location.href attribute for every window in the protected document's window parent chain MUST be parsed into its component parts, and the resulting scheme, host and port tuple MUST be present in the source list defined by the frame-ancestors directive in order for the protected document to be used in the embedded browsing context.

    If the frame-ancestors directive is not present in a policy its value MUST be assumed to be *, or all sources.

    User-agents MUST NOT render a protected document in an embedded browsing context if any window in the protected document's window parent chain has a location.href representing a non-approved source.

    We may want to remove frame-ancestors from Content Security Policy as IETF is standardizing an equivalent feature in its Frame Options draft.

    report-uri

    The report-uri directive defines one or more URIs to which a violation report is sent when a policy violation occurs.

    If the report-uri directive is present in a policy the user-agent MUST send a violation report to each valid URI specified in the directive value.

    The violation report MUST be sent via an HTTP POST request whose body is comprised of a JSON object containing violation information, and the request MUST have a Content-Type of application/json.

    The URIs specified in the report-uri directive value MUST have the same scheme and port as the protected document and MUST

    sandbox

    A future version of this document might include a sandbox directive for controlling the HTML5 sandbox flags.

    report-uri

    The report-uri directive specifies a URI to which the user agent sends reports about policy violation. The syntax for the name and value of the directive are described by the following ABNF grammar:

    
    directive-name    = "report-uri"
    directive-value   = uri-reference *( 1*WSP uri-reference )
    uri-reference     = <URI-reference from RFC 3986>
    
    

    Let the set of report URIs be the value of the report-uri directive, each resolved relative to the protected document's URI.

    To send a violation report, the user agent MUST use an algorithm equivalent to the following:

    1. Prepare a dictionary violation dictionary with the following keys and values:
      request
      HTTP request line of the protected resource whose policy was violated including method, URI and HTTP version
      request-headers
      HTTP request headers sent with the request for the protected resource whose policy was violated
      blocked-uri
      URI of the resource that was prevented from loading due to the policy violation
      violated-directive
      The policy directive that was violated
      original-policy
      The original policy as received by the user-agent. If the policy was received via more than one Content Security Policy response header, this field MUST contain a comma separated list of original policies

      We might need to change some of these keys because they can leak sensitive information.

    2. If the origin of the blocked-uri is not the same as the document's origin, then replace the blocked-uri with the ASCII serialization of the blocked-uri's origin.
    3. Let the violation report be the JSON stringification of the violation dictionary.
    4. For each report URI in the set of report URIs:
      1. If the report URI has a different scheme than the URI of the protected document, then ignore this report URI and continue to the next iteration of the loop.
      2. If the report URI has a different port than the URI of the protected document, then ignore this report URI and continue to the next iteration of the loop.
      3. If the report URI's host does not share the same public suffix +1 DNS label as the URI of the protected document
    in order to be treated as valid
      1. , then ignore this report URI and continue to the next iteration of the loop.

        Examples of public suffixes include .com, .net and .co.uk. Examples of "public suffix +1 DNS label" include example.com, example.net and example.co.uk. Therefore a protected document whose host is www.example.com could have a report-uri hosted on reports.example.com but not reports.example.net.

    User-agents MUST send violation reports to all valid URIs listed in the report-uri directive value.

    User-agents MUST NOT send violation reports to any invalid URIs listed in the report-uri directive value.

    User-agents MUST NOT follow HTTP 3xx redirect responses when sending violation reports.

    User-agents MUST resolve a report-uri relative to the protected document's location.

    User-agents SHOULD log policy violations on the error console when they occur.

    This section is very HTTP-centric regarding report sending. Is it proper to require HTTP POST, for instance, if the report-uri uses the ftp: scheme? Should non-HTTP schemes be allowed for reports?

    policy-uri

    The policy-uri directive defines the location of a file containing the policy for a protected resource. The contents of the file comprise the complete policy for the protected resource.

    The policy-uri directive MUST only be declared in the absence of all other policy directives.

    If the policy-uri directive is present in a policy and no other policy directives are declared the user-agent MUST fetch the URI defined in the policy-uri directive value and parse the content returned as the complete security policy for the protected resource.

    If the policy-uri directive is present in a policy and any other policy directive is also declared the user-agent MUST enforce the policy default-src 'none'.

    The URI specified in the policy-uri directive value MUST have the same origin as the protected document in order to be treated as valid.

    User-agents MUST NOT fetch an invalid policy-uri and when one is encountered the user-agent MUST enforce the policy default-src 'none'.

    The response to a policy-uri request MUST include a Content-Type of text/x-content-security-policy in order for the response to be treated as valid policy for the protected resource. User-agents MUST NOT enforce a policy retrieved from a policy-uri that does not have the required Content-Type and
      1. Fetch the report URI from origin of the protected document, with the synchronous flag not set, using HTTP method POST, with a Content-Type header field of application/json with an entity body consisting of the violation report. The user agent MUST NOT follow redirects when fetching this resource. (Note: The user agent ignores the fetched resource.)

    policy-uri

    The policy-uri directive specifies a URI from which the user agent can retrieve the actual policy. The syntax for the name and value of the directive are described by the following ABNF grammar:

    
    directive-name    = "policy-uri"
    directive-value   = <URI-reference from RFC 3986>
    
    

    The policy-uri directive might be removed from this document.

    Authors MUST NOT specify policies that contain both a policy-uri directive and another directive.

    If the user agent would enforce a policy containing both the policy-uri directive and another directive, instead the user agent MUST enforce the policy default-src 'none'

    when such a response is received.

    User-agents MUST NOT follow HTTP 3xx redirect responses when fetching a policy-uri.

    User-agents MUST resolve a policy-uri relative to the protected document's location.

    options

    The options directive defines a set of modifications to the Content Security Policy base restrictions.

    The options directive value is comprised of a space-separated LDH tokens, each specifying a modification to the default Content Security Policy processing model.

    User-agents MUST ignore any unrecognized options tokens and when an unrecognized options token is encountered, user-agents SHOULD log the event on the error console.

    Source Expressions

    This section describes the structure of the directive values that restrict the loading of content into a protected document.

    A source expression represents a combination of a scheme, a set of hosts, and a network port from which content may be loaded. Source expressions may contain a wildcard, *, used to match a set of hosts or a set of ports.

    A source expression may specify a set of hosts represented by any number of DNS labels and an optional leading hostname wildcard which matches 0 or more leading DNS labels. If 0 DNS labels are specified in the source expression, a wildcard represents the set of URIs.

    Examples of host-only source expressions are example.net and *.example.com.

    Source expressions may specify a scheme and/or port from which content is limited to loading from. Content loading may be restricted to a single scheme by declaring the scheme at the beginning of a source expression. Content loading may also be restricted to a particular port by declaring the port number at the end of a source expression. A port wildcard * may also be used in place of a single port number to permit content from any port.

    If a scheme is not specified as part of the source expression, a user-agent MUST use the same scheme as the protected document. If a port number is not specified as part of the source expression, a user-agent MUST use the default port for the source's scheme, whether the scheme was explicitly stated in the source expression or was inherited from the protected document.

    An example of a source expression specifying a scheme restriction is https://example.com. An example of a source expression specifying scheme and port restrictions is https://*.example.org:443.

    A source expression may consist entirely of a scheme. In this case, user-agents MUST only restrict content to be loaded from the specified scheme and MUST NOT apply any host or port restrictions. This allows host-less schemes to be used as sources in security policies.

    User-agents MUST treat all invalid source expressions encountered in a directive value as empty.

    Servers MUST specify internationalized domain names in security policies according to their punycode representations. [RFC 3492]

    Host-less Schemes

    All source expressions do not require a hostname. Schemes like data: can be used to load inline content and do not require a hostname or port number.

    data: is an example of a complete and valid source expression that specifies neither hostname nor port number and which permits data URIs to be used for content loading.

    Hostname Wildcards

    A source expression MAY contain a single wildcard character, *, in the hostname portion and it MUST be used in place of the left-most, or most specific, DNS label. The wildcard character matches zero or more DNS labels.

    Examples of valid source expressions using hostname wildcards include *.example.com, *.org and *

    Examples of invalid hostname wildcards use include www.*.com, *.example.* and example.*

    Port Wildcards

    A source expression MAY contain a single wildcard character, *, in place of the port number. The wildcard character indicates that any port may be used to load content.

    Examples of valid source expressions using the port wildcard include example.com:* and http://example.net:*.

    User-agents MAY prevent content from being loaded via specific ports, even when the port wildcard is used, due to security reasons.

    Source Expression Keywords

    A source expression MAY make use of one of the following keywords which either serves as a shorthand replacement for a set of hosts or modifies a default behavior for a particular directive.

    Source expression keywords begin and end with a single-quote character in order to differentiate them from network hosts of the same name.

    The 'none' keyword represents the empty set of hosts. If used, no hosts are permitted for that directive.

    The 'self' keyword represents the source serving the protected resource. When used, content may be loaded from the scheme, host and port that the protected resource was served from.

    The 'unsafe-inline' keyword may be used to enable a particular type of content to be loaded inline, or from within the protected resource. Only a subset of the directives support this keyword. When used, content of the type referenced by the containing directive may be loaded inline. More details regarding which directives support this keyword are provided in the directives section.

    The 'unsafe-eval' keyword may be used to enable a set of ECMAScript APIs that turn strings into code which are restricted by default when the script-src directive is specified. script-src is the only directive that supports this keyword.

    User-agents MUST ignore any unrecognized source expression keywords.

    Formal Policy Grammar

    This section describes the formal grammar of Content Security Policy using a simple ABNF notation. Each rule in the grammar defines one symbol in the form:

    symbol = expression
    

    The expression on the right-hand side of a rule consists of one or more sequences of symbols. A complete sequence represents a possible substitution for the symbol on the left-hand side of the rule. A choice between sequences is indicated by a forward slash "/". Expression symbols that do not appear on the left-hand side of any rule are terminal symbols. Sequence groups are enclosed in parentheses "(...)" and are treated as a single, ordered element. Symbol repetitions are preceded by an asterisk "*". If a minimum number of repetitions is required, the asterisk is preceded by that number.

    The following core rules are included by reference, as defined in [ABNF Appendix B.1]: ALPHA (letters), DIGIT (decimal 0-9), WSP (white space) and VCHAR (printing characters).

    Content Security Policy Grammar

    This section defines the general syntax of Content Security Policies as well as some grammar symbols used in the directive syntax definitions.

    
    policy            = directive-list
    
    directive-list    = [ directive *( ";" [ directive ] ) ]
    
    directive         = *WSP [ directive-name [ WSP directive-value ] ]
    
    directive-name    = 1*( ALPHA / DIGIT / "-" )
    
    directive-value   = *( WSP / <VCHAR except ";"> )
    
    source-list       = *WSP [ source *( 1*WSP source ) *WSP ]
                      / *WSP "'none'" *WSP
    
    source            = scheme ":"
                      / ( [ scheme "://" ] host [ port ] )
                      / "'self'"
                        ; <scheme> production from RFC 3986
    
    host              = [ "*." ] 1*host-char *( "." 1*host-char )
                      / "*"
    
    host-char         = ALPHA / DIGIT / "-"
    
    port              = ":" ( 1*DIGIT / "*" )
    
    option-value      = 1*( ALPHA / DIGIT / "-" )
    
    

    Directive Definitions

    This section defines the syntax of each directive introduced by this specification.

    
    default-src       = "default-src" [ WSP source-list ]
    
    script-src        = "script-src" [ WSP source-list ]
    
    object-src        = "object-src" [ WSP source-list ]
    
    img-src           = "img-src" [ WSP source-list ]
    
    media-src         = "media-src" [ WSP source-list ]
    
    style-src         = "style-src" [ WSP source-list ]
    
    frame-src         = "frame-src" [ WSP source-list ]
    
    font-src          = "font-src" [ WSP source-list ]
    
    connect-src       = "connect-src" [ WSP source-list ]
    
    frame-ancestors   = "frame-ancestors" [ WSP source-list ]
    
    report-uri        = "report-uri" *( 1*WSP <URI> ) *WSP
                        ; <URI> production from RFC 2396
    
    policy-uri        = "policy-uri" 1*WSP <URI> *WSP
                        ; <URI> production from RFC 2396
    
    options           = "options" *( 1*WSP option-value ) *WSP
    
    

    .

    When processing the policy-uri directive, the user agent MUST run an algorithm equivalent to the following:

    Examples

    Sample Policy Definitions

    This section provides some sample use cases and accompanying security policies.

    Example 1: A server wants all content to come from wishes to load resources only form its own domainorigin:

    X-Content-Security-Policy: default-src 'self'

    Example 2: An auction site wants wishes to allow load images from anywhere, plugin any URI, plug-in content from a list of trusted media providers (including a content distribution network), and scripts only from a server under its control hosting sanitized ECMAScript:

    X-Content-Security-Policy: default-src 'self'; img-src *;
    \                            object-src media1.example.com media2.example.com *.cdn.example.com;
    \                            script-src trustedscripts.example.com

    Example 3: A site operations group wants wishes to globally deny all third-party scripts in the site, and a particular project team wants wishes to also disallow third-party media in their section of the site. Site operations sends the first header while the project team sends the second header, and the user-agent takes the intersection combination of the two headers to form the complete interpreted policy:

    X-Content-Security-Policy: default-src *; script-src 'self'
    X-Content-Security-Policy: default-src *; script-src 'self'; media-src 'self'

    Example 4: Online banking site wants wishes to ensure that all of the content in its pages is loaded over TLS to prevent attackers from eavesdropping on insecure content requests:

    X-Content-Security-Policy: default-src https://*:443
    

    Sample Violation Report

    Syntax

    This section

    defines the structure of the violation report sent by a user-agent when a protected resource's security policy is violated.

    A user-agent MUST send a violation report in the following two cases:

  • Whenever ANY policy violation occurs, a user-agent MUST dispatch a SecurityViolation event which does not bubble and is not cancelable at the Document object of the protected resource.
  • Whenever a policy violation occurs and the server's policy

    contains

    a report-uri, a user-agent MUST send a violation report to all valid report URIs declared in the policy via an HTTP POST request bearing the Content-Type application/json.

    The SecurityViolation DOM event and the violation report sent by a user-agent convey the same information about the policy violation and are intended to be utilized by the server for monitoring and logging.

    The SecurityViolation event uses the CustomEvent interface defined in the DOM Level 3 Events specification. [[!DOM-LEVEL-3-EVENTS]].

    The report structure defined below is a JSON object used for both the detail argument to the SecurityViolation event constructor and the request body of the violation report.

    The SecurityViolation event detail and the report body sent by the user-agent MUST be comprised of a JSON object having the following properties:

    If the origin of the blocked-uri is not the same as the document's origin, then the user agent MUST replace the blocked-uri with the ASCII serialization of the blocked-uri's origin.

    In the case where a protected resource is not rendered because its frame-ancestors directive is violated, user-agents MUST NOT send blocked-uri in the report as it is assumed to have the same value as request.

    Sample Policy Violation Report

    In the following example a page located at

    an example violation report the user agent might sent to a server when the protected document violations a sample policy.

    In the following example, a document from http://example.org/page.html was

    requested and returned with its response a policy of

    rendered with the following CSP policy:

    default-src 'self'; report-uri http://example.org/csp-report.cgi
    
    . The policy was violated by

    The document loaded an image

    element

    from http://evil.example.com

    which had been embedded in the page

    /image.png, violating the policy.

    {
      "csp-report": {
        "request": "GET http://example.org/page.html HTTP/1.1",
        "request-headers": "Host: example.org
                            User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre
                            Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
                            Accept-Language: en-us,en;q=0.5
                            Accept-Encoding: gzip, deflate
                            Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
                            Keep-Alive: 115
                            Proxy-Connection: keep-alive
                            Cache-Control: max-age=0",
        "blocked-uri": "http://evil.example.com/image.png",
        "violated-directive": "default-src http://example.org"
      }
    }
    

    In the above sample report the violated-directive field was sent in the way it was interpreted by the user-agent. The directive was made explicit by replacing the keyword 'self' with the explicit host name of the protected resource. This is recommended behavior for user-agents as it reduces ambiguity, making policy violations easier to trace by server admins.

    User-Agent Behavior

    This section describes required behavior for conformant user-agents when processing a Content Security Policy and applying restrictions to a protected resource.

    Base Restrictions

    The following restrictions MUST be applied by a user-agent rendering a protected resource which has declared a Content Security Policy containing at least one valid directive, except in cases where the policy includes directives which disable or modify the restrictions.

    data: URIs MUST NOT be permitted

    User-agents MUST prevent data: URIs from being used to load inline content unless the protected document's policy explicitly permits the data: protocol for that type of content.

    If a protected resource's policy declares a report-uri and this base restriction is violated, user-agents MUST generate a violation report with fields set appropriately to describe the violation and MUST send the report to the report-uri specified in the policy.

    Enabling data: URIs

    Inline content can be loaded via data: URIs by adding the data: source expression to the directive that restricts that particular type of content.

    For example, a site that wishes to load inline images via data: URIs would add the directive img-src data: to their policy.

    CSS-ECMAScript bindings MUST come from chrome: or resource: URIs

    User-agents which allow external ECMAScript content to be bound to document elements via CSS rules MUST prevent such bindings unless the external content is served as a chrome: or resource: URI.

    An example of such a CSS-ECMAScript binding technology is XBL. [[!XBL]]

    This restriction prevents untrusted remote content from being injected into a document via a stylesheet because both the chrome: and resource: protocols serve only local, trusted content.

    If a protected resource's policy declares a report-uri and this base restriction is violated, user-agents MUST generate a violation report with fields set appropriately to describe the violation and MUST send the report to the report-uri specified in the policy.

    Script Execution Restrictions

    This section describes required restrictions which MUST be applied by a user-agent rendering a protected resource which has declared ANY directive which controls the loading of ECMAScript content into the protected resource. Such directives include: script-src and object-src, as well as an implied value for either of these directives as indicated by a default-src directive. If a script-src directive has not been declared in the policy a user-agent MUST NOT enforce the following restrictions.

    It may be preferable to only activate these restrictions when script-src is declared.

    Inline scripts MUST NOT execute

    User-agents MUST prevent inline scripts from executing. These include:

    • Contents of internal <script> elements
    • javascript: URIs
    • Event-handling HTML attributes

    The supported method for executing ECMAScript in a protected document is to include <script> elements in the document whose sources are permitted by the protected document's policy. User-agents MUST execute all external scripts whose src attribute refers to a permitted source and which are served with a Content-Type of application/javascript or application/json.

    If a protected resource's policy declares a report-uri and this restriction is violated, user-agents MUST generate a violation report and MUST send the report to the report-uri specified in the policy.

    Enabling inline scripts

    Inline script can be enabled by adding the 'unsafe-inline' source expression keyword to the script-src directive. It is not recommended to do so, however, as all cross-site scripting protection provided by Content Security Policy will be effectively disabled.

    There is an alternate proposal for enabling inline script by Collin Jackson which uses an 'inline' source expression keyword in script-src but ignores it unless disable-xss-protection is declared as an options token.

    Code MUST NOT be created from strings

    User-agents MUST prevent strings from being converted to ECMAScript code, including calls to:

    • eval(). Instead of evaluating their arguments, both operator eval and function eval MUST throw a security exception.
    • new Function(). When called as a constructor, the Function function MUST throw a security exception.
    • setTimeout(). When called with a first argument that is non-callable (e.g., not a function), the setTimeout function MUST return zero without creating a timer.
    • setInterval(). When called with a first argument that is non-callable (e.g., not a function), the setInterval function MUST return zero without creating a timer.

    Should setTimeout and setInterval throw security exceptions rather than returning zero?

    The term callable refers to an object whose interface has one or more callers as defined in the Web IDL specification [[!WEBIDL]].

    If a protected resource's policy declares a report-uri and this restriction is violated, user-agents MUST generate a violation report and MUST send the report to the report-uri specified in the policy.

    Enabling strings-into-code functionality

    The APIs listed above that turn strings into executable code can be enabled by adding the 'unsafe-eval' source expression keyword to the script-src directive. It is not recommended to do so, however, as the risk of DOM-based cross-site scripting will be greatly increased.

    Inline CSS Restrictions

    This section describes required restrictions which MUST be applied by a user-agent rendering a protected resource which has declared a style-src directive, or has implied a style-src directive by declaring a default-src directive. If a style-src directive has not been declared in the policy a user-agent MUST NOT enforce the following restrictions.

    Inline CSS MUST NOT be applied

    User-agents MUST prevent inline CSS from being applied to the protected document. This includes CSS properties defined in:

    • <style> elements
    • style attributes on HTML elements

    The supported method for applying CSS properties to a protected resource which utilizes the style-src directive is to include <link rel="stylesheet"> elements in the document whose sources are permitted by the protected document's policy. User-agents MUST parse and apply all style properties from external stylesheets whose href attribute refers to a permitted source.

    If a protected resource's policy declares a report-uri and this restriction is violated, user-agents MUST generate a violation report and MUST send the report to the report-uri specified in the policy.

    Enabling inline CSS

    Inline CSS can be enabled by adding the 'unsafe-inline' source expression keyword to the style-src directive.

    Interpreting Multiple Policies

    When multiple instances of the Content Security Policy response header are present in a single HTTP response, the user-agent MUST enforce the most restrictive intersection of the policies received. This means that no action can be taken by the user-agent when rendering the protected document unless every policy directive of every policy header received permits such an action. If an action taken by a user-agent will violate any of the policy directives received in any response header, that action MUST NOT be taken by the user-agent.

    Is a description of a policy intersection algorithm necessary?

    When differing report-uri values are received in multiple policy headers the intersection of the policy values is NOT taken. Rather, user-agents MUST send a single report to each valid URI specified in any report-uri directive received in a policy header.

    When multiple Content Security Policy <meta> elements are present in the head section of a protected resource, the first <meta> element MUST be parsed as the document's security policy and enforced. All subsequent policy <meta> elements MUST be ignored by the user-agent.

    What should happen when multiple instances of the same directive but with different values occur within a single policy header or meta element, i.e. should they be combined or intersected as they are successively parsed?

    Handling Policy Parsing Errors

    This section describes how user-agents should handle various error conditions encountered when parsing Content Security Policies. The error conditions described in this section are distinct from the policy violations described earlier in this document. While policy violations MUST be reported to servers when a policy-uri has been declared, policy parsing warnings SHOULD be reported locally in the user-agent's error console, and SHOULD NOT be reported to the remote server.

    Unrecognized Directive

    When a user-agent receives a directive name that it does not recognize, the user-agent MUST not parse the directive name or value and MUST skip ahead to the next directive name present in the policy or to the end of the policy if no further directives are declared. The user-agent SHOULD report a warning message to the error console containing the unrecognized directive name.

    Invalid Directive

    When a user-agent receives a directive name that violates all of the directive syntax, the user-agent MUST not parse the directive name or value and MUST skip ahead to the next directive name present in the policy or to the end of the policy if no further directives are declared. The user-agent SHOULD report a warning message to the error console containing the invalid directive name.

    Unrecognized options Token

    When a user-agent receives a token in an options directive that it does not recognize, the user-agent MUST skip over it. User-agents SHOULD report a warning message to the error console containing the unrecognized token.

    Directive Syntax Error

    When a user-agent receives a policy directive that violates Content Security Policy syntax, the user-agent MUST discard the entire policy and enforce a policy of default-src 'none' on the protected resource. User-agents SHOULD report a warning message to the error console communicating that an invalid policy was received.

    No Recognized Directives

    When a user-agent receives a policy that contains no directives recognized by the user-agent, the user-agent MUST NOT enforce any restrictions on the protected resource. User-agents SHOULD report a warning message to the error console communicating that a policy containing no valid directives was received.

    Other Parsing Errors

    Any other parsing errors not described in the above sections MUST result in the user-agent enforcing a policy of default-src 'none' on the protected resource and SHOULD result in the user-agent reporting a warning message to the error console describing the error.

    Report-Only Mode

    This section describes a mode of operation for user-agents in which security policies are parsed and violations are logged as they occur, but without blocking content from loading or executing as the user-agent would under normal processing of Content Security Policy.

    Content Security Policy can be deployed by servers in report-only mode by sending a X-Content-Security-Policy-Report-Only response header or by placing a <meta http-equiv="X-Content-Security-Policy-Report-Only"> policy element in the <head> section of a document.

    When report-only mode is enabled by a server, the user-agent MUST log all policy violations and policy parsing errors in the same manner that it would in normal blocking mode, including sending violation reports to the server if a report-uri directive is present, as well as logging any appropriate errors or warnings locally to the error console. In report-only mode, the user-agent MUST NOT prevent any content from loading or executing normally due to violations of the protected document's stated security policy.

    This mode of operation is intended to ease deployment for servers that want to experiment with a security policy but aren't ready to take the step of policy enforcement. Such sites can develop a security policy according to their knowledge and assumptions about how the site functions and receive reports when content in the site behaves in a manner contrary to the developed policy. Report-only mode can also be used in parallel with blocking mode as it is a useful test vehicle for a stricter policy. The stricter report-only policy can be deployed in production environments with no compatibility risk and feedback can be collected from any violation reports received. Once a site has confidence that the policy is appropriate, they can promote the report-only policy to normal blocking mode.

    Other User-Agent Considerations

    This section contains miscellaneous items for consideration by user-agent implementers.

    User Scripts

    Content Security Policy should not interfere with the operation of user-supplied scripts such as third-party user-agent add-ons and JavaScript bookmarklets.

    Redirecting Content Loads

    For any protected document, when a request for a sub-document resource is redirected to another location, whether temporary or permanent, all locations in the resource's redirect chain, including the initial location and all subsequent redirected locations, must be permitted by the protected document's security policy in order for the sub-document resource to be allowed to load. If any step in the redirect process violates the protected document's security policy, the request should be terminated immediately and the load canceled.

    Future Directives

    In order to support new policy directives in the future, user-agents must parse but ignore unrecognized directives. For this reason, this document specifies that user-agents MUST skip over unrecognized directives but SHOULD report them on the error console.

    HTTP Server Behavior

    This section describes required behavior for conformant servers when emitting a Content Security Policy.

    HTTP Header Placement

    The Content Security Policy HTTP response header MAY be present in the Message Headers section of a server's HTTP response.

    The Content Security Policy HTTP response header MUST NOT be present in the Trailer section of a server's HTTP response. If a user-agent receives a Content Security Policy as an HTTP Trailer, it MUST NOT parse the policy or attempt to enforce any restrictions on the rendered document.

    HTTP Message Headers and Trailers are defined in the HTTP 1.1 standard. [[!HTTP11]]

    Should we add this as a requirement when preparing reports?