 first | Daisy 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  |
| first | Daisy 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.
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.
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.
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:
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
its security policy for a particular resource as a
collection of directives, such as default-src 'self', each of which controls a specific set of
privileges for a document rendered by a user-agent.
More details are provided in the directives section.
A directive
consists of a directive name, which indicates the
privileges controlled by the
directive, and a directive value, which specifies the
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
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
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
Window object
are defined in the
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].
The
This section describes the content security policy directives introduced in this specification.
This section defines the syntax and semantics of the policy directives and policy delivery mechanisms introduced by this specification.
TheAugmented 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).
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.
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.
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
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.
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:
http-equiv="content-security-policy")
meta element lacks a content attribute, abort these steps.
content attribute of the meta element.
http-equiv="content-security-policy-report-only")
meta element lacks a content attribute, abort these steps.
content attribute of the meta element.
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]]
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.
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.
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:
;):
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:
'none' (including the quotation marks), return the empty set.
source-expression, add the token to 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:
*), then return does match.
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.
host-source:
scheme that is not a case insensitive match for scheme, then return does not match.
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.
host, then return does not match.
port and port is not the default port for scheme, then return does not match.
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.
'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.
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'.
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.
This section describes the content security policy directives introduced in this specification.
In order to protect against Cross-site Scripting (XSS), authors SHOULD include
script-src and object-src directives, or
default-src directive, which covers both scripts and plug-ins.
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
<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:
src attributes on <script> elements within HTML documents
scriptURL arguments passed to the the Worker and SharedWorker constructors within HTML documents
href attributes on <xsl:include> elements within XML documents
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:
data attributes on <object> elements
src attributes on <embed> elements
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.
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:
script element or from an inline event handler), instead the user agent MUST NOT execute script.
javascript URI, instead the user agent MUST NOT execute the script. (Note: The user agent SHOULD execute script contained in "bookmarklets" even when enforcing this restriction.)
If 'unsafe-eval' is not in allowed script sources:
eval and function eval MUST throw a security exception.
Function MUST throw a security exception.
setTimeout function MUST return zero without creating a timer.
setInterval function MUST return zero without creating a timer.
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:
src attribute of a script element or when processing the Worker or SharedWorker constructors.
<?xml-stylesheet?> processing directive in an XML document, the href attributes on <xsl:include> element, or the href attributes on <xsl:import> element.
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:
data attribute of an object element, the src attribute of an embed elements, or the code or archive attributes of an applet element.
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:
style element, instead the user agent MUST ignore the style.
style attribute, instead the user agent MUST ignore the style.
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:
href attribute of a link element with a rel attribute containing the token stylesheet or when processing the @import directive in a stylesheet.
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:
src attribute of an img elements, the url() or image() values on any CSS property that is capable of loading an image
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.
href attribute of a link element with an image-related rel attribute, such as icon.
Should the user agent fire the error event when one of these loads fails?
If theimg-src directive is not present in a policy and the
media-src
The media-src directive
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.
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:
src attribute of a video or audio elements.
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:
src attribute of an iframe or frame element.
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
@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:
@font-face CSS rule. TODO: Citation needed.
connect-src
The connect-src directive
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.
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:
open() method of an XMLHttpRequest object
url argument passed to
WebSocket constructor
url argument passed to
EventSource constructor
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.
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:
We might need to change some of these keys because they can leak sensitive information.
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'.
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
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'
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.
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]
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.
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.*
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.
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.
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).
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 / "-" )
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:
policy-uri directive relative to the URI of the protected document.
default-src 'none'.
GET.
200 or if the request encountered an HTTP redirect, abort these steps and enforce the policy default-src 'none'.
Content-Type header field or if the Content-Type header field is not a case insensitive match for text/x-content-security-policy, abort these steps and enforce the policy default-src 'none'.
policy-uri directive, abort these steps and enforce the policy default-src 'none'.
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
This section
A user-agent MUST send a violation report in the following two cases:
SecurityViolation event which does not bubble and is not cancelable at the Document object of the protected resource.
contains
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:
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.
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.
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
rendered with the following CSP policy:
default-src 'self'; report-uri http://example.org/csp-report.cgi
The document loaded an image
from http://evil.example.com
/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.
This section describes required behavior for conformant user-agents when processing a Content Security Policy and applying restrictions to a protected resource.
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.
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.
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.
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.
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.
User-agents MUST prevent inline scripts from executing. These include:
<script> elements
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.
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.
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.
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.
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.
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.
Inline CSS can be enabled by adding the 'unsafe-inline' source expression keyword to the style-src directive.
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?
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.
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.
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.
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.
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.
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.
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.
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.
This section contains miscellaneous items for consideration by user-agent implementers.
Content Security Policy should not interfere with the operation of user-supplied scripts such as third-party user-agent add-ons and JavaScript bookmarklets.
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.
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.
This section describes required behavior for conformant servers when emitting a Content Security Policy.
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?