1. Introduction
\n\n\nThis section is not normative.
\n\n\nThis document defines Content Security Policy, a mechanism web applications\n can use to mitigate a broad class of content injection vulnerabilities, such\n as cross-site scripting (XSS). Content Security Policy is a declarative policy\n that lets the authors (or server administrators) of a web application inform\n the client about the sources from which the application expects to load\n resources.
\n\n\nTo mitigate XSS attacks, for example, a web application can declare that it\n only expects to load script from specific, trusted sources. This declaration\n allows the client to detect and block malicious scripts injected into the\n application by an attacker.
\n\n\nContent Security Policy (CSP) is not intended as a first line of defense\n against content injection vulnerabilities. Instead, CSP is best used as\n defense-in-depth, to reduce the harm caused by content injection attacks. As\n a first line of defense against content injection, server operators should\n validate their input and encode their output.
\n\n\nThere is often a non-trivial amount of work required to apply CSP to an\n existing web application. To reap the greatest benefit, authors will need to\n move all inline script and style out-of-line, for example into external\n scripts, because the user agent cannot determine whether an inline script\n was injected by an attacker.
\n\n\nTo take advantage of CSP, a web application opts into using CSP by supplying a\n Content-Security-Policy HTTP header. Such policies apply to the\n current resource representation only. To supply a policy for an entire site,\n the server needs to supply a policy with each resource representation.
1.1. Changes from Level 1
\n\n\nThis document describes an evolution of the\n Content Security Policy specification.\n Level 2 makes two breaking changes from Level 1, and adds support for a number\n of new directives and capabilities which are summarized below:
\n\n \n- \n \n
- \n The following changes are backwards incompatible with the majority of\n user agent’s implementations of CSP 1:\n\n \n
- \n \n
- \n The path component of a source expression is now ignored if the\n resource being loaded is the result of a redirect, as described in\n §4.2.2.3 Paths and Redirects.\n\n\n
Note: Paths are technically new in CSP2, but they were already\n implemented in many user agents before this revision of CSP was\n completed, so noting the change here seems reasonable.
\n \n \n \n \n - \n Redirects are blocked by default, and explicitly allowed with a new\n
unsafe-redirectexpression.\n \n \n \n - \n A protected resource’s ability to load Workers is now controlled\n via
child-srcrather than\nscript-src.\n \n \n \n - \n Workers now have their own policy, separate from the protected\n resource which loaded them. This is described in\n §5.1 Workers.\n \n \n \n
- \n The path component of a source expression is now ignored if the\n resource being loaded is the result of a redirect, as described in\n §4.2.2.3 Paths and Redirects.\n\n\n
- \n The following directives are brand new in this revision:\n\n \n
- \n \n
- \n
base-uricontrols the protected\n resource’s ability to specify the document base\n URL.\n \n \n \n - \n
child-srcdeprecates and replaces\nframe-src, controlling the protected\n resource’s ability to embed frames, and to load Workers.\n \n \n \n - \n
form-actioncontrols the protected\n resource’s ability to submit forms.\n \n \n \n - \n
frame-ancestorscontrols the protected\n resource’s ability be embedded in other documents. It is meant\n to supplant theX-Frame-OptionsHTTP request header.\n \n \n \n - \n
plugin-typescontrols the protected\n resource’s ability to load specific types of plugins.\n \n \n \n
- \n
- \n Individual inline scripts and stylesheets may be whitelisted via nonces\n (as described in §4.2.4 Valid Nonces) and hashes (as described\n in §4.2.5 Valid Hashes).\n \n \n \n
- \n A
CSPrequest header is now sent with relevant requests, as\n described in §3.4 The CSP HTTP Request Header.\n \n \n \n - \n A
SecurityPolicyViolationEventis fired upon violations, as described\n in §6.3 Firing Violation Events.\n \n \n \n - \n A number of new fields were added to violation reports (both those POSTED\n via
report-uri, and those handed to the DOM via\nSecurityPolicyViolationEventevents. These include\neffectiveDirective,\nstatusCode,\nsourceFile,\nlineNumber, and\ncolumnNumber.\n \n \n \n - \n Certain flags present in the
sandboxdirective now\n affect Worker creation, as described in §7.14.1 Sandboxing and Workers.\n \n \n \n
2. Key Concepts and Terminology
\n\n \n2.1. Terms defined by this specification
\n \n- \n \n
- \n security policy\n \n \n \n
- \n security policy directive\n \n \n \n
- \n security policy directive name\n \n \n \n
- \n security policy directive value\n \n \n \n
- \n security policy directive\n \n \n \n
- \n A security policy refers to both a set of security\n preferences for restrictions within which content can operate, and\n to a fragment of text that codifies or transmits these preferences.\n For example, the following string is a policy which restricts script\n and object content:\n\n \n \n\n \n\n\n
script-src 'self'; object-src 'none'\nSecurity policies contain a set of security policy\n directives (
\n \n\n\nscript-srcand\nobject-srcin the example above), each responsible\n for declaring the restrictions for a particular resource type, or\n manipulating a specific aspect of the policy’s restrictions. The list\n of directives defined by this specification can be found in\n §7 Directives.Each directives has a name and a value;\n a detailed grammar can be found in §4 Syntax and Algorithms.
\n \n \n \n \n - \n protected resource\n \n \n \n
- \n A security policy is applied by a user agent to a specific\n resource representation, known as the protected\n resource. See §3 Policy Delivery for details regarding\n the mechanisms by which policies may be applied to a protected\n resource.\n \n \n \n
2.2. Terms defined by reference
\n \n- \n \n
- \n globally unique identifier\n \n \n \n
- \n Defined in\n Section 2.3 of\n the Origin specification. [RFC6454]\n\n\n
NOTE: URLs which do not use hierarchical elements as naming authorities\n (
\n \n \n \n \ndata:, for instance) have origins which are globally\n unique identifiers. - \n HTTP 200 response\n \n \n \n
- \n Defined in\n Section\n 6.3.1 of HTTP/1.1 -- Semantics and Content. [RFC7231]\n \n \n \n
- \n JSON object\n \n \n \n
- \n JSON stringification\n \n \n \n
- \n Defined in the JSON specification. [RFC4627]\n \n \n \n
- \n origin\n \n \n \n
- \n Defined by the Origin specification. [RFC6454]\n \n \n \n
- \n resource representation\n \n \n \n
- \n Defined in Section\n 3 of HTTP/1.1 -- Semantics and Content. [RFC7231]\n \n \n \n
- \n URL\n \n \n \n
- \n Defined by [URL].\n \n \n \n
- SHA-256\n \n \n
- SHA-384\n \n \n
- SHA-512\n \n \n
- SHA-384\n \n \n
- \n These digest algorithms are defined by the NIST. [SHA2]\n \n \n \n
2.3. Relevant Concepts from HTML
\n\n\nThe applet, audio, embed, iframe, img, link,\n object, script, source, track, and video are defined in\n [HTML5].
The terms auxiliary browsing contexts,\n opener browsing context, and nested browsing contexts are\n defined in the HTML5 specification. [HTML5]
\n\n\nA plugin is defined in the HTML5 specification. [HTML5]
\n\n\nThe <@font-face> Cascading Style Sheets (CSS) rule is defined\n in the CSS Fonts Module Level 3 specification. [CSS3-FONTS]
The XMLHttpRequest object is defined in the\n XMLHttpRequest specification. [XMLHTTPREQUEST]
The WebSocket object is defined in the WebSocket\n specification. [WEBSOCKETS]
The EventSource object is defined in the EventSource\n specification. [EVENTSOURCE]
The runs a worker algorithm is\n defined in the Web\n Workers spec. [WORKERS]
\n\n\nThe term callable refers to an object whose interface\n has one or more callers as defined in the Web\n IDL specification [WEBIDL].
\n\n \n2.4. Grammatical Concepts
\n\n\nThe Augmented Backus-Naur Form (ABNF) notation used in this document is\n specified in RFC5234. [ABNF]
\n\n\nThis document also uses the ABNF extension \"#rule\" as defined in\n Section 7\n of HTTP/1.1 -- Message Syntax and Routing. [RFC7230]
\n\n\nThe following core rules are included by reference, as defined in\n Appendix B.1\n of [ABNF]: ALPHA (letters),\n DIGIT (decimal 0-9), WSP\n (white space) and VCHAR (printing characters).
3. Policy Delivery
\n\n\nThe server delivers a policy to the user agent via an HTTP response\n header (defined in §3.1 \n Content-Security-Policy Header Field\n and\n §3.2 \n Content-Security-Policy-Report-Only Header Field\n ) or an HTML\n meta element (defined in §3.3 \n HTML meta Element\n ).
Servers are informed that requests are coming from a protected resource\n via an HTTP request header (defined in §3.4 The CSP HTTP Request Header).
\n\n \n3.1. \n Content-Security-Policy Header Field\n
\n \n\n\n The Content-Security-Policy header field is\n the preferred mechanism for delivering a policy. The grammar is as follows:
\"Content-Security-Policy:\" 1#policy-token\n\n \n\n\n
For example, a response might include the following header field:
\n \n\n \nContent-Security-Policy: script-src 'self'\n A server MUST NOT send more than one HTTP header field named\n Content-Security-Policy with a given resource\n representation.
A server MAY send different Content-Security-Policy\n header field values with different representations of the same\n resource or with different resources.
Upon receiving an HTTP response containing at least one\n Content-Security-Policy header field, the user agent\n MUST enforce each of the policies contained in each such\n header field.
3.2. \n Content-Security-Policy-Report-Only Header Field\n
\n \n\n\n The Content-Security-Policy-Report-Only\n header field lets servers experiment with policies by monitoring (rather\n than enforcing) a policy. The grammar is as follows:
\"Content-Security-Policy-Report-Only:\" 1#policy-token\n\n \n\n\n
For example, server operators might wish to develop their\n security policy iteratively. The operators can deploy a report-only\n policy based on their best estimate of how their site behaves:
\n \n\n \nContent-Security-Policy-Report-Only: script-src 'self';\n report-uri /csp-report-endpoint/\n\n \n \n
If their site violates this policy the user agent will send violation\n reports to the URL specified in the policy’s report-uri\n directive, but allow the violating resources to load regardless. Once a site\n has confidence that the policy is appropriate, they can start enforcing the\n policy using the Content-Security-Policy header field.
A server MUST NOT send more than one HTTP header field named\n Content-Security-Policy-Report-Only with a given\n resource representation.
A server MAY send different\n Content-Security-Policy-Report-Only header field values\n with different representations of the same resource or with different\n resources.
Upon receiving an HTTP response containing at least one\n Content-Security-Policy-Report-Only header field, the\n user agent MUST monitor each of the policies\n contained in each such header field.
Note: The Content-Security-Policy-Report-Only\n header is not supported inside a meta element.
3.3. \n HTML meta Element\n
\n \n\n\n The server MAY supply policy via one or more HTML meta elements\n with http-equiv attributes that are an ASCII case-insensitive\n match for the string \"Content-Security-Policy\". For\n example:
<meta http-equiv=\"Content-Security-Policy\" content=\"script-src 'self'\">\n\n \n\n\n
Add the following entry to the pragma directives for the meta\n element:
- \n \n
- \n Content security policy\n (
http-equiv=\"content-security-policy\")\n \n \n \n - \n \n
- \n \n
- If the Document’s
headelement is not an ancestor of the\nmetaelement, abort these steps.\n \n\n \n - If the
metaelement lacks acontentattribute, abort\n these steps.\n \n\n \n - Let policy be the value of the
content\n attribute of themetaelement.\n \n\n \n - Let directive-set be the result of\n parsing policy.\n \n\n \n
- \n Remove all occurrences of
report-uri,\nframe-ancestors, andsandbox\n directives from directive-set.\n\n\nNote: User agents are encouraged to issue a warning to developers\n if one or more of these directives are included in a policy\n delivered via
\n \n \n \n\n \nmeta. - Enforce each of the directives in directive-set,\n as defined for each directive type.\n \n \n
- If the Document’s
Authors are strongly encouraged to place meta elements as early\n in the document as possible, because policies in meta elements are not\n applied to content which preceeds them. In particular, note that resources\n fetched or prefetched using the Link HTTP response header\n field, and resources fetched or prefetched using link and script\n elements which preceed a meta-delivered policy will not be blocked.
Note: A policy specified via a meta element will be enforced\n along with any other policies active for the protected resource, regardless\n of where they’re specified. The general impact of enforcing multiple\n policies is described in §3.5 Enforcing multiple policies..
Note: Modifications to the content attribute of a meta element\n after the element has been parsed will be ignored.
Note: The Content-Security-Policy-Report-Only\n header is not supported inside a meta element.
3.4. The CSP HTTP Request Header
\n \n\n\n The CSP header field indicates that a particular\n request is subject to a policy, and its value is defined by the\n following ABNF grammar:
\"CSP:\" 1#csp-header-value\n\ncsp-header-value = *WSP \"active\" *WSP\n\n \n\n\n
If the user agent is monitoring or enforcing a policy\n that includes directives whose value is a source list, and whose\n source list contains the 'unsafe-redirect' source expression,\n then the user agent MUST send a header field named CSP\n along with requests for resources whose origin does not\n match the protected resource’s origin. The value of this header MUST\n be active.
The user agent MAY choose to send this header only if the request is for a\n resource type which the active policy would effect. That is, given a policy\n of img-src example.com 'unsafe-redirect', the user agent\n would send CSP: active along with requests for images, but\n might choose not to send the header with requests for script.
Note: The central reason for including this header is that it hints to a\n server that information about redirects might be leaked as a side-effect\n of a page’s active policy. If this header is present, a server might decline\n to redirect a logged-out user from example.com to\n accounts.example.com, for example, as a malicious embedder\n might otherwise be able to determine the user’s logged-in status.
3.5. Enforcing multiple policies.
\n \n\n\nThis section is not normative.
\n \n\n\nThe above sections note that when multiple policies are present,\n each must be enforced or reported, according to its type. An example\n will help clarify how that ought to work in practice. The behavior of\n an XMLHttpRequest might seem unclear given a site\n that, for whatever reason, delivered the following HTTP headers:
Content-Security-Policy: default-src 'self' http://example.com http://example.net;\n connect-src 'none';\nContent-Security-Policy: connect-src http://example.com/;\n script-src http://example.com/\n\n \n\n\n
Is a connection to example.com allowed or not? The\n short answer is that the connection is not allowed. Enforcing both\n policies means that a potential connection would have to pass through\n both unscathed. Even though the second policy would allow this\n connection, the first policy contains connect-src\n 'none', so its enforcement blocks the connection. The impact is\n that adding additional policies to the list of policies to enforce can\n only further restrict the capabilities of the protected resource.
To demonstrate that further, consider a script tag on this page.\n The first policy would lock scripts down to 'self',\n http://example.com and http://example.net\n via the default-src directive. The second, however,\n would only allow script from http://example.com/. Script\n will only load if it meets both policy’s criteria: in this case, the only\n origin that can match is http://example.com, as both\n policies allow it.
3.6. Policy applicability
\n \n\n\nThis section is not normative.
\n \n\n\nPolicies are associated with an protected resource, and\n enforced or monitored for that resource.\n If a resource does not create a new execution context (for example, when\n including a script, image, or stylesheet into a document), then any policies\n delivered with that resource are discarded without effect. Its execution is\n subject to the policy or policies of the including context. The following\n table outlines examples of these relationships:
\n \n\n \n| Resource Type\n \n \n | What policy applies?\n \n \n \n \n \n \n | |
|---|---|---|
| Top-level Contexts\n \n\n \n | HTML as a new, top-level browsing context\n \n \n | The policy delivered with the resource\n \n \n \n \n |
| SVG, as a top-level document\n \n \n | Policy delivered with the resource\n \n \n \n\n \n | |
| Embedded Contexts\n \n\n \n | \n Any resource included via iframe, object, or embed\n \n \n \n | \n The policy of the embedding resource controls what may be\n embedded. The embedded resource, however, is controlled by the\n policy delivered with the resource, or the policy of the embedding\n resource if the embedded resource is a globally unique\n identifier (or a srcdoc frame).\n \n \n \n \n \n |
| SVG, as an embedded document\n \n \n | \n The policy delivered with the resource, or policy of the creating\n context if created from a globally unique identifier.\n \n \n \n \n \n | |
| \n JavaScript, as a Worker, Shared Worker or Service Worker\n \n \n \n | \n The policy delivered with the resource, or policy of the creating\n context if created from a globally unique identifier\n \n \n \n \n\n \n | |
| Subresources\n \n\n \n | SVG, inlined via svg\n \n \n | Policy of the including context\n \n \n \n \n |
| SVG, as a resource document\n \n \n | Policy of the including context\n \n \n \n \n | |
| HTML via XMLHttpRequest\n \n \n | Policy of the context that performed the fetch\n \n \n \n \n | |
Image via img element\n \n \n | Policy of the including context\n \n \n \n \n | |
JavaScript via a script element\n \n \n | Policy of the including context\n \n \n \n \n | |
SVG, via img\n \n \n | No policy; should be just as safe as JPG\n \n \n \n \n | |
| SVG, as a WebFont\n \n \n | No policy; should be just as safe as WOFF\n \n \n \n \n \n \n |
4. Syntax and Algorithms
\n \n4.1. Policy Syntax
\n \n\n\nA Content Security Policy consists of a U+003B SEMICOLON\n (;) delimited list of directives. Each directive\n consists of a directive name and (optionally) a\n directive value, defined by the following ABNF:
policy-token = [ directive-token *( \";\" [ directive-token ] ) ]\ndirective-token = *WSP [ directive-name [ WSP directive-value ] ]\ndirective-name = 1*( ALPHA / DIGIT / \"-\" )\ndirective-value = *( WSP / <VCHAR except \";\" and \",\"> )\n\n \n\n \n
4.1.1. Parsing Policies
\n \n\n\nTo parse the policy policy, the user agent MUST\n use an algorithm equivalent to the following:
\n \n\n \n- \n \n
- Let the set of directives be the empty set.\n \n\n \n
- For each non-empty token returned by\n strictly splitting\n the string policy on the character U+003B SEMICOLON\n (
;):\n \n- \n \n
- Skip whitespace.\n \n\n \n
- Collect a sequence of characters that are\n not space characters. The collected characters\n are the directive name.\n \n\n \n
- If there are characters remaining in token,\n skip ahead exactly one character (which must be a\n space character).\n \n\n \n
- The remaining characters in token (if any) are\n the directive value.\n \n\n \n
- If the set of directives already contains a\n directive whose name is a case insensitive match for\n directive name, ignore this instance of the directive\n and continue to the next token.\n \n\n \n
- Add a directive to the set of\n directives with name directive name and value\n directive value.\n \n \n
- Return the set of directives.\n \n
4.2. Source List Syntax
\n \n\n\nMany CSP directives use a value consisting of a source\n list, defined in the ABNF grammar below.
\n \n\n\nEach source expression in the source list represents a\n location from which content of the specified type can be retrieved.\n For example, the source expression 'none' represents\n the empty set of URLs, and the source expression\n 'unsafe-inline' represents content supplied inline in the\n resource itself.
source-list = *WSP [ source-expression *( 1*WSP source-expression ) *WSP ]\n / *WSP \"'none'\" *WSP\nsource-expression = scheme-source / host-source / keyword-source / nonce-source / hash-source\nscheme-source = scheme-part \":\"\nhost-source = [ scheme-part \"://\" ] host-part [ port-part ] [ path-part ]\nkeyword-source = \"'self'\" / \"'unsafe-inline'\" / \"'unsafe-eval'\" / \"'unsafe-redirect'\"\nbase64-value = 1*( ALPHA / DIGIT / \"+\" / \"/\" )*2( \"=\" )\nnonce-value = base64-value\nhash-value = base64-value\nnonce-source = \"'nonce-\" nonce-value \"'\"\nhash-algo = \"sha256\" / \"sha384\" / \"sha512\"\nhash-source = \"'\" hash-algo \"-\" hash-value \"'\"\nscheme-part = <scheme production from RFC 3986, section 3.1>\nhost-part = \"*\" / [ \"*.\" ] 1*host-char *( \".\" 1*host-char )\nhost-char = ALPHA / DIGIT / \"-\"\npath-part = <path production from RFC 3986, section 3.3>\nport-part = \":\" ( 1*DIGIT / \"*\" )\n\n \n\n\n
If the policy contains a nonce-source expression, the\n server MUST generate a fresh value for the nonce-value\n directive at random and independently each time it transmits a policy.\n The generated value SHOULD be at least 128 bits long (before encoding),\n and generated via a cryptographically secure random number generator.\n This requirement ensures that the nonce-value is\n difficult for an attacker to predict.
Note: Using a nonce to whitelist inline script or style is less secure than\n not using a nonce, as nonces override the restrictions in the directive in\n which they are present. An attacker who can gain access to the nonce can\n execute whatever script they like, whenever they like. That said, nonces\n provide a substantial improvement over 'unsafe-inline' when\n layering a content security policy on top of old code. When considering\n 'unsafe-inline', authors are encouraged to consider nonces (or\n hashes) instead.
The host-char production intentionally contains only\n ASCII characters; internationalized domain names cannot be entered\n directly into a policy string, but instead MUST be Punycode-encoded\n [RFC3492]. For example, the domain üüüüüü.de would be\n encoded as xn--tdaaaaaa.de.
NOTE: Though IP addresses do match the grammar above, only\n 127.0.0.1 will actually match a URL when used in a source\n expression (see §4.2.2 Matching Source Expressions for details). The security\n properties of IP addresses are suspect, and authors ought to prefer\n hostnames to IP addresses whenever possible.
4.2.1. Parsing Source Lists
\n \n\n\nTo parse a source list\n source list, the user agent MUST use an algorithm\n equivalent to the following:
\n \n\n \n- \n \n
- Strip leading and trailing whitespace from\n source list.\n \n\n \n
- If source list is an ASCII case-insensitive match\n for the string
'none'(including the quotation\n marks), return the empty set.\n \n\n \n - Let set of source expressions be the empty\n set.\n \n\n \n
- For each token returned by\n splitting source\n list on spaces, if the token matches the grammar for\n
source-expression, add the token to the set\n of source expressions.\n \n\n \n - Return the set of source expressions.\n \n \n
Note: Characters like U+003B SEMICOLON (;) and\n U+002C COMMA (,) cannot appear in source expressions\n directly: if you’d like to include these characters in a source\n expression, they must be percent\n encoded as %3B and %2C respectively.
4.2.2. Matching Source Expressions
\n \n\n\nA URL url is said to match a source expression for\n a protected resource if the following algorithm returns\n does match:
\n \n\n \n- \n \n
- \n Let url be the result of processing the URL through the\n URL parser.\n \n \n\n \n
- \n If the source expression a consists of a single U+002A ASTERISK\n character (
*), and url’s scheme is not\n one ofblob,data,filesystem,\n then return does match.\n \n \n\n \n - \n If the source expression matches the grammar for\n
scheme-source:\n\n \n- \n \n
- \n If url’s scheme is an ASCII case-insensitive\n match for the source expression’s\n
scheme-part, return does match.\n \n \n\n \n - \n Otherwise, return does not match.\n \n \n \n
- \n If url’s scheme is an ASCII case-insensitive\n match for the source expression’s\n
- \n If the source expression matches the grammar for\n
host-source:\n\n \n- \n \n
- \n If url’s host is
null,\n return does not match.\n \n \n \n - \n Let url-scheme, url-host, and\n url-port be the scheme, host, and\n port of url’s origin, respectively.\n\n\n
Note: If url doesn’t specify a port, then its origin’s\n port will be the default port for url’s\n scheme.
\n \n \n \n \n - \n Let url-path-list be the path of url.\n \n \n \n
- \n If the source expression has a
scheme-part\n that is not a case insensitive match for url-scheme,\n then return does not match.\n \n \n \n - \n If the source expression does not have a\n scheme, return does not match if any of the following\n are true:\n\n \n
- \n \n
- \n the scheme of the protected resource’s URL is a case\n insensitive match for
HTTP, and\n url-scheme is not a case\n insensitive match for eitherHTTPor\nHTTPS\n \n \n \n - \n the scheme of the protected resource’s URL is\n not a case insensitive match for\n
HTTP, and url-scheme is\n not a case insensitive match\n for the scheme of the protected resource’s URL.\n \n \n \n
- \n the scheme of the protected resource’s URL is a case\n insensitive match for
- \n If the first character of the source expression’s\n
host-partis an U+002A ASTERISK character\n (*) and the remaining characters, including the\n leading U+002E FULL STOP character (.), are not a\n case insensitive match for the rightmost characters of\n url-host, then return does not match.\n \n \n\n \n - \n If the first character of the source expression’s\n
host-partis not an U+002A ASTERISK\n character (*) and url-host is not a\n case insensitive match for the source expression’s\nhost-part, then return does not\n match.\n \n \n\n \n - \n If the source expression’s
host-partmatches\n theIPv4addressproduction from [RFC3986],\n and is not127.0.0.1, or is an IPv6 address,\n return does not match.\n\n\nNote: A future version of this specification may allow literal\n IPv6 and IPv4 addresses, depending on usage and demand. Given the\n weak security properties of IP addresses in relation to named\n hosts, however, authors are encouraged to prefer the latter\n whenever possible.
\n \n \n \n\n \n - \n If the source expression does not contain\n a
port-partand url-port is not the\n default port for url-scheme, then return\n does not match.\n \n \n\n \n - \n If the source expression does contain a
port-part,\n then return does not match if both of the following\n are true:\n\n \n \n \n \n \n\n \n - \n If the source expression contains a non-empty\n
path-part, and the URL is not the\n result of a redirect, then:\n\n \n- \n \n
- \n Let exact-match be
trueif the final\n character of path-part is not the U+002F SOLIDUS\n character (/), andfalseotherwise.\n \n \n\n \n - \n Let source-expression-path-list be the result of\n splitting path-part on the U+002F SOLIDUS character\n (
/).\n \n \n\n \n - \n If source-expression-path-list’s length is greater\n than url-path-list’s length, return does not\n match.\n \n \n\n \n
- \n For each entry in\n source-expression-path-list:\n\n \n
- \n \n
- \n Percent decode entry.\n \n \n \n
- \n Percent decode the first item in\n url-path-list.\n \n \n \n
- \n If entry is not an ASCII case-insensitive\n match for the first item in url-path-list,\n return does not match.\n \n \n \n
- \n Pop the first item in url-path-list off the\n list.\n \n \n \n
- \n If exact-match is
true, and\n url-path-list is not empty, return does not\n match.\n \n \n \n
- \n Let exact-match be
- \n Otherwise, return does match.\n \n \n \n
- \n If url’s host is
- \n If the source expression is a case insensitive match for\n
'self'(including the quotation marks), then:\n\n \n- \n \n
- \n Return does match if the\n origin of url matches\n the origin of protected\n resource’s URL.\n\n\n
Note: This includes IP addresses. That is, a document at\n
\n \n \n \n \nhttps://111.111.111.111/with a policy of\nimg-src 'self'can load the image\nhttps://111.111.111.111/image.png, as the origins\n match.
- \n Return does match if the\n origin of url matches\n the origin of protected\n resource’s URL.\n\n\n
- \n Otherwise, return does not match.\n \n \n \n
Note: This algorithm treats the URLs https://example.com/\n and https://example.com./ as non-matching. This\n is consistent with browser behavior which treats documents served from\n these URLs as existing in distinct origins.
A URL url is said to match a source list for\n protected resource if the following conditions are met:
\n \n\n \n- \n \n
- \n At least one source expression in the set of source expressions\n obtained by parsing the source\n list matches url\n for protected resource.\n \n \n \n
- \n At least one of the following is true:\n\n \n
- \n \n
- \n url is not the result of a redirect.\n\n\n
Note: This is a bit hand-wavey; in the future, CSP will cleanly\n integrate with [FETCH], which will allow us to clarify the\n details.
\n \n \n \n \n - \n The set of source expressions obtained by\n parsing the source list\n contains the source expression
'unsafe-redirect'.\n \n \n \n - \n The source list is the U+002A ASTERISK character (
*).\n \n \n \n
- \n url is not the result of a redirect.\n\n\n
Note: No URLs match an empty set of source expressions, such as the set\n obtained by parsing the source list 'none'.
4.2.2.1. \n Security Considerations for GUID URL schemes\n
\n \n\n\nThis section is not normative.
\n \n\n\nAs defined above, special URL schemes that refer to specific pieces of\n unique content, such as \"data:\", \"blob:\" and \"filesystem:\" are\n excluded from matching a policy of * and must be\n explicitly listed. Policy authors should note that the content of\n such URLs is often derived from a response body or execution in a\n Document context, which may be unsafe. Especially for the\n default-src and script-src\n directives, policy authors should be aware that allowing \"data:\" URLs\n is equivalent to unsafe-inline and allowing \"blob:\" or\n \"filesystem:\" URLs is equivalent to unsafe-eval.
4.2.2.2. Path Matching
\n \n\n\nThis section is not normative.
\n \n\n\nThe rules for matching source expressions that contain paths\n are simpler than they look: paths that end with the '/'\n character match all files in a directory and its subdirectories. Paths\n that do not end with the '/' character match only one\n specific file. A few examples should make this clear:
- \n \n
- The source expression
example.comhas no path,\n and therefore matches any file served from that host.\n \n\n \n - The source expression
example.com/scripts/\n matches any file in thescriptsdirectory of\nexample.com, and any of its subdirectories. For\n example, bothhttps://example.com/scripts/file.js\n andhttps://example.com/scripts/js/file.jswould\n match.\n \n\n \n - The source expression\n
example.com/scripts/file.jsmatches only the file\n namedfile.jsin thescriptsdirectory\n ofexample.com.\n \n\n \n - Likewise, the source expression
example.com/js\n matches only the file namedjs. In particular, note\n that it would not match files inside a directory named\njs. Files likeexample.com/js/file.js\n would be matched only if the source expression ended with a\n trailing \"/\", as inexample.com/js/.\n \n \n
Note: Query strings have no impact on matching: the source\n expression example.com/file matches all of\n https://example.com/file,\n https://example.com/file?key=value,\n https://example.com/file?key=notvalue, and\n https://example.com/file?notkey=notvalue.
4.2.2.3. Paths and Redirects
\n \n\n\nTo avoid leaking path information cross-origin (as discussed\n in Egor Homakov’s\n Using Content-Security-Policy for Evil),\n the matching algorithm ignores the path component of a source\n expression if the resource being loaded is the result of a\n redirect. For example, given a page with an active policy of\n img-src example.com not-example.com/path:
- \n \n
- Directly loading
https://not-example.com/not-path\n would fail, as it doesn’t match the policy.\n \n \n - Directly loading
https://example.com/redirector\n would pass, as it matchesexample.com.\n \n \n - Assuming that
https://example.com/redirector\n delivered a redirect response pointing tohttps://not-example.com/not-path,\n the load would succeed, as the initial URL matchesexample.com,\n and the redirect target matchesnot-example.com/path\n if we ignore its path component.\n \n \n
This restriction reduces the granularity of a document’s\n policy when redirects are in play, which isn’t wonderful, but\n given that we certainly don’t want to allow brute-forcing paths\n after redirects, it seems a reasonable compromise.
\n \n\n\nThe relatively long thread\n \"Remove paths from CSP?\"\n from public-webappsec@w3.org has more detailed discussion around\n alternate proposals.
\n \n \n4.2.3. \n The nonce attribute\n
\n \n\n\n Nonce sources require a new nonce attribute to be added to\n both script and style elements.
partial interface HTMLScriptElement {\n attribute DOMString /nonce\n \n \n\" data-link-type=\"attribute\" data-type=\"DOMString \" href=\"#dom-htmlscriptelement-nonce\">nonce ;\n};\n
- \n \n
- nonce, of type DOMString\n \n \n
- This attribute reflects the value of the\n element’s
nonce\n content attribute.\n \n \n
partial interface HTMLStyleElement {\n attribute DOMString /nonce\n \n \n \n \n\n \n\" data-link-type=\"attribute\" data-type=\"DOMString \" href=\"#dom-htmlstyleelement-nonce\">nonce ;\n};\n
4.2.4. Valid Nonces
\n \n\n\nAn element has a valid nonce for a set of source\n expressions if the value of the element’s nonce attribute\n after stripping leading\n and trailing whitespace is a case-sensitive match for the\n nonce-value component of at least one\n nonce-source expression in set of source\n expressions.
4.2.5. Valid Hashes
\n \n\n\nAn element’s content is the script block’s\n source for script elements, or the value of the element’s\n textContent IDL attribute for non-script elements such as\n style.
The digest of element’s content for is the result\n of applying an algorithm to the element’s content.
\n \n\n\nTo determine whether element has a valid hash for\n a set of source expressions, execute the following steps:
\n \n\n \n- \n \n
- Let hashes be a list of all\n
hash-sourceexpressions in set of source\n expressions.\n \n\n \n - For each hash in hashes:\n \n
- \n \n
- Let algorithm be:\n \n
- \n \n
- SHA-256 if the
hash-algo\n component of hash is an ASCII case-insensitive\n match for the string \"sha256\"\n \n\n \n - SHA-384 if the
hash-algo\n component of hash is an ASCII case-insensitive\n match for the string \"sha384\"\n \n\n \n - SHA-512 if the
hash-algo\n component of hash is an ASCII case-insensitive\n match for the string \"sha512\"\n \n \n
- SHA-256 if the
- Let expected be the
hash-value\n component of hash.\n \n\n \n - Let actual be the\n base64\n encoding of the binary digest of element’s\n content using the algorithm algorithm.\n \n\n \n
- If actual is a case-sensitive match for\n expected, return true and abort these\n steps.\n \n \n
- Let algorithm be:\n \n
- Return false.\n \n \n
Note: If an element has an invalid hash, it would be helpful\n if the user agent reported the failure to the author by adding\n a warning message containing the actual hash value.
\n \n \n4.3. Media Type List Syntax
\n \n\n\nThe plugin-types directive uses a value consisting\n of a media type list.
Each media type in the media type list represents a specific\n type of resource that can be retrieved and used to instantiate a\n plugin in the protected resource.
\n \n\n \nmedia-type-list = media-type *( 1*WSP media-type )\nmedia-type = <type from RFC 2045> \"/\" <subtype from RFC 2045>\n\n \n\n \n
4.3.1. Parsing
\n \n\n\nTo parse a media type list media type list, the\n user agent MUST use an algorithm equivalent to the following:
\n \n\n \n- \n \n
- Let the set of media types be the empty set.\n \n\n \n
- For each token returned by\n splitting\n media type list on spaces, if the token matches the\n grammar for
media-type, add the token to the\n set of media types. Otherwise ignore the token.\n \n\n \n - Return the set of media types.\n \n \n
4.3.2. Matching
\n \n\n\nA media type matches a media type\n list if, and only if, the media type is an ASCII\n case-insensitive match for at least one token in the set of media\n types obtained by parsing the media\n type list.
\n \n \n4.4. Reporting
\n \n\n\nTo strip\n uri for reporting, the user agent MUST use an\n algorithm equivalent to the following:
\n \n\n \n- \n \n
- If the origin of uri is a globally unique\n identifier (for example, uri has a scheme of\n
data,blob, orfilesystem), then\n abort these steps, and return the ASCII serialization of\n uri’s scheme.\n \n\n \n - If the origin of uri is not the same as the\n origin of the protected resource, then abort these steps, and\n return the\n ASCII\n serialization of uri’s origin.\n \n\n \n
- Return uri, with any fragment\n component removed.\n \n \n
To generate a violation report object,\n the user agent MUST use an algorithm equivalent to the following:
\n \n\n \n- \n \n
- Prepare a JSON object violation with the\n following keys and values:\n\n \n
- \n \n
- blocked-uri\n \n \n
- The originally requested URL of the resource that was\n prevented from loading, stripped for reporting,\n or the empty string if the resource has no URL (inline script and\n inline style, for example).\n \n\n \n
- document-uri\n \n \n
- The address\n of the protected resource, stripped for reporting.\n \n\n \n
- effective-directive\n \n \n
- The name of the policy directive that was violated. This will\n contain the directive whose enforcement triggered the\n violation (e.g. \"
script-src\") even if that\n directive does not explicitly appear in the policy, but is\n implicitly activated via thedefault-src\n directive.\n \n\n \n - original-policy\n \n \n
- The original policy, as received by the user agent.\n \n\n \n
- referrer\n \n \n
- The referrer attribute of the protected\n resource, or the empty string if the protected resource has no\n referrer.\n \n\n \n
- status-code\n \n \n
- The
status-codeof the HTTP response that\n contained the protected resource, if the protected resource was\n obtained over HTTP. Otherwise, the number 0.\n \n\n \n - violated-directive\n \n \n
- The policy directive that was violated, as it appears in the\n policy. This will contain the
default-srcdirective\n in the case of violations caused by falling back to the\n default sources when enforcing\n a directive.\n \n \n
- If a specific line or a specific file can be identified as the\n cause of the violation (for example, script execution that violates\n the
script-srcdirective), the user agent MAY add the\n following keys and values to violation:\n\n \n- \n \n
- source-file\n \n \n
- The URL of the resource where the violation occurred,\n stripped for reporting.\n \n\n \n
- line-number\n \n \n
- The line number in
source-fileon which\n the violation occurred.\n \n\n \n - column-number\n \n \n
- The column number in
source-fileon which\n the violation occurred.\n \n \n
- Return violation.\n \n \n
Note: blocked-uri will not contain the final location of a\n resource that was blocked after one or more redirects. It instead will\n contain only the location that the protected resource requested, before\n any redirects were followed.
To send violation reports, the user agent MUST use an\n algorithm equivalent to the following:
\n \n\n \n- \n \n
- Prepare a JSON object report object with a single\n key,
csp-report, whose value is the result of generating\n a violation report object.\n \n\n \n - Let report body be the JSON stringification of\n report object.\n \n\n \n
- For each report URL in the set of report URLs:\n \n
- \n \n
- If the user agent has already sent a violation report for\n the protected resource to report URL, and that report\n contained an entity body that exactly matches\n report body, the user agent MAY abort these\n steps and continue to the next report URL.\n \n\n \n
- Queue a task to fetch\n report URL from the origin of the protected resource,\n with the synchronous flag not set, using HTTP method\n
POST, with aContent-Typeheader field\n ofapplication/csp-report, and an entity body\n consisting of report body. If the origin of\n report URL is not the same as the\n origin of the protected resource, the block cookies flag MUST also\n be set. The user agent MUST NOT follow redirects when fetching this\n resource. (Note: The user agent ignores the fetched resource.)\n The task source for these\n tasks is the Content Security Policy task\n source.\n \n \n
To report a violation, the user agent MUST:
\n \n\n \n- \n \n
- Fire a violation event at the protected resource’s\n
Document.\n \n\n \n - If the set of report URLs is non-empty, send violation\n reports to each.\n \n \n
Note: This section of the specification should not be interpreted\n as limiting user agents' ability to apply restrictions to violation\n reports in order to limit data leakage above and beyond what these\n algorithms specify. For example, a user agent might offer users the\n option of disabling reporting entirely.
\n \n \n5. Processing Model
\n\n\nTo enforce a policy, the user agent MUST parse the policy\n and enforce each of the directives contained in the policy, where the\n specific requirements for enforcing each directive are defined separately\n for each directive (See §7 Directives, below).
\n\n\nGenerally speaking, enforcing a directive prevents the protected\n resource from performing certain actions, such as loading scripts from\n URLs other than those indicated in a source list. These restrictions\n make it more difficult for an attacker to abuse an injection\n vulnerability in the resource because the attacker will be unable to\n usurp the resource’s privileges that have been restricted in this\n way.
\n\n\nNote: User agents may allow users to modify or bypass policy enforcement\n through user preferences, bookmarklets, third-party additions to the user\n agent, and other such mechanisms.
\n\n\nTo monitor a policy, the user agent MUST parse the policy\n and monitor each of the directives contained in the policy.
\n\n\nMonitoring a directive does not prevent the protected resource from\n undertaking any actions. Instead, any actions that would have been\n prevented by the directives are allowed, but a violation report is\n generated and reported to the\n developer of the web application. Monitoring a policy is useful for\n testing whether enforcing the policy will cause the web application to\n malfunction.
\n\n\nA server MAY cause user agents to monitor one policy while enforcing\n another policy by returning both Content-Security-Policy\n and Content-Security-Policy-Report-Only header fields.\n For example, if a server operator may wish to enforce one policy but\n experiment with a stricter policy, she can monitor the stricter policy while\n enforcing the original policy. Once the server operator is satisfied that\n the stricter policy does not break the web application, the server operator\n can start enforcing the stricter policy.
If the user agent monitors or enforces a policy that does not contain any\n directives, the user agent SHOULD report a warning message in the\n developer console.
\n\n\nIf the user agent monitors or enforces a policy that contains\n an unrecognized directive, the user agent SHOULD report a warning message\n in the developer console indicating the name of the unrecognized directive.
\n\n\nIf the user agent monitors or enforces a policy that contains\n a directive that contains a source list, then the user agent MUST set\n a CSP Request Header when requesting cross-origin\n resources, as described in §3.4 The CSP HTTP Request Header.
5.1. Workers
\n \n\n\nWhenever a user agent runs a worker:
\n \n\n \n- \n \n
- If the worker’s script’s origin is a globally unique identifier\n (for example, the worker’s script’s URL has a scheme of\n
data,blob, orfilesystem), then:\n \n- \n \n
- If the user agent is enforcing a CSP policy for the owner\n document or parent worker, the user agent MUST enforce\n the CSP policy for the worker.\n \n\n \n
- If the user agent is monitoring a CSP policy for the owner\n document or parent worker, the user agent MUST monitor\n the CSP policy for the worker.\n \n \n
- Otherwise:\n \n
- \n \n
- If the worker’s script is delivered with a\n
Content-Security-PolicyHTTP header containing the\n value policy, the user agent MUST enforce\n policy for the worker.\n \n\n \n - If the worker’s script is delivered with a\n
Content-Security-Policy-Report-OnlyHTTP header\n containing the value policy, the user agent MUST\n monitor policy for the worker.\n \n \n
- If the worker’s script is delivered with a\n
5.2. srcdoc IFrames
\n \n\n\n Whenever a user agent creates an iframe\n srcdoc document in a browsing context nested in the\n protected resource, if the user agent is enforcing any policies\n for the protected resource, the user agent MUST enforce those\n policies on the iframe srcdoc document as well.
Whenever a user agent creates an iframe\n srcdoc document in a browsing context nested in the\n protected resource, if the user agent is monitoring any policies for the\n protected resource, the user agent MUST monitor those policies on\n the iframe srcdoc document as well.
6. Script Interfaces
\n\n \n6.1. \n SecurityPolicyViolationEvent Interface\n
\n \n\n \n [/SecurityPolicyViolationEvent(type, eventInitDict)\n \n \n\" data-lt=\"SecurityPolicyViolationEvent(type, eventInitDict)\" id=\"dom-securitypolicyviolationevent-securitypolicyviolationeventtype-eventinitdict\">Constructor (DOMString /SecurityPolicyViolationEvent(type, eventInitDict)/type , optional SecurityPolicyViolationEventInit /SecurityPolicyViolationEvent(type, eventInitDict)\" id=\"dom-securitypolicyviolationevent-securitypolicyviolationeventtype-eventinitdict-type\">type /eventInitDict )]\ninterface SecurityPolicyViolationEvent : Event {\n readonly attribute DOMString /documentURI\" id=\"dom-securitypolicyviolationevent-securitypolicyviolationeventtype-eventinitdict-eventinitdict\">eventInitDict \" data-link-type=\"attribute\" data-readonly=\"\" data-type=\"DOMString \" href=\"#dom-securitypolicyviolationevent-documenturi\">documentURI ;\n readonly attribute DOMString /referrer\" data-link-type=\"attribute\" data-readonly=\"\" data-type=\"DOMString \" href=\"#dom-securitypolicyviolationevent-referrer\">referrer ;\n readonly attribute DOMString /blockedURI\" data-link-type=\"attribute\" data-readonly=\"\" data-type=\"DOMString \" href=\"#dom-securitypolicyviolationevent-blockeduri\">blockedURI ;\n readonly attribute DOMString /violatedDirective\" data-link-type=\"attribute\" data-readonly=\"\" data-type=\"DOMString \" href=\"#dom-securitypolicyviolationevent-violateddirective\">violatedDirective ;\n readonly attribute DOMString /effectiveDirective\" data-link-type=\"attribute\" data-readonly=\"\" data-type=\"DOMString \" href=\"#dom-securitypolicyviolationevent-effectivedirective\">effectiveDirective ;\n readonly attribute DOMString /originalPolicy\" data-link-type=\"attribute\" data-readonly=\"\" data-type=\"DOMString \" href=\"#dom-securitypolicyviolationevent-originalpolicy\">originalPolicy ;\n readonly attribute DOMString /sourceFile\" data-link-type=\"attribute\" data-readonly=\"\" data-type=\"DOMString \" href=\"#dom-securitypolicyviolationevent-sourcefile\">sourceFile ;\n readonly attribute DOMString /statusCode\" data-link-type=\"attribute\" data-readonly=\"\" data-type=\"DOMString \" href=\"#dom-securitypolicyviolationevent-statuscode\">statusCode ;\n readonly attribute long /lineNumber\" data-link-type=\"attribute\" data-readonly=\"\" data-type=\"long \" href=\"#dom-securitypolicyviolationevent-linenumber\">lineNumber ;\n readonly attribute long /columnNumber\" data-link-type=\"attribute\" data-readonly=\"\" data-type=\"long \" href=\"#dom-securitypolicyviolationevent-columnnumber\">columnNumber ;\n};\n
- \n \n
- documentURI, of type DOMString, readonly\n \n \n
- Refer to the
document-uriproperty of violation reports for a description of this property.\n \n \n - referrer, of type DOMString, readonly\n \n \n
- Refer to the
referrerproperty of violation reports for a description of this property.\n \n \n - blockedURI, of type DOMString, readonly\n \n \n
- Refer to the
blocked-uriproperty of violation reports for a description of this property.\n \n \n - violatedDirective, of type DOMString, readonly\n \n \n
- Refer to the
violated-directiveproperty of violation reports for a description of this property.\n \n \n - effectiveDirective, of type DOMString, readonly\n \n \n
- Refer to the
effective-directiveproperty of violation reports for a description of this property.\n \n \n - originalPolicy, of type DOMString, readonly\n \n \n
- Refer to the
original-policyproperty of violation reports for a description of this property.\n \n \n - statusCode, of type DOMString, readonly\n \n \n
- Refer to the
status-codeproperty of violation reports for a description of this property.\n \n \n - sourceFile, of type DOMString, readonly\n \n \n
- Refer to the
source-fileproperty of violation reports for a description of this property.\n \n \n - lineNumber, of type long, readonly\n \n \n
- Refer to the
line-numberproperty of violation reports for a description of this property.\n \n \n - columnNumber, of type long, readonly\n \n \n
- Refer to the
column-numberproperty of violation reports for a description of this property.\n \n \n
6.2. \n SecurityPolicyViolationEventInit Interface\n
\n \n\n \n dictionary SecurityPolicyViolationEventInit : EventInit {\n DOMString /documentURI\n \n \n\" data-link-type=\"dict-member\" data-type=\"DOMString \" href=\"#dom-securitypolicyviolationeventinit-documenturi\">documentURI ;\n DOMString /referrer\" data-link-type=\"dict-member\" data-type=\"DOMString \" href=\"#dom-securitypolicyviolationeventinit-referrer\">referrer ;\n DOMString /blockedURI\" data-link-type=\"dict-member\" data-type=\"DOMString \" href=\"#dom-securitypolicyviolationeventinit-blockeduri\">blockedURI ;\n DOMString /violatedDirective\" data-link-type=\"dict-member\" data-type=\"DOMString \" href=\"#dom-securitypolicyviolationeventinit-violateddirective\">violatedDirective ;\n DOMString /effectiveDirective\" data-link-type=\"dict-member\" data-type=\"DOMString \" href=\"#dom-securitypolicyviolationeventinit-effectivedirective\">effectiveDirective ;\n DOMString /originalPolicy\" data-link-type=\"dict-member\" data-type=\"DOMString \" href=\"#dom-securitypolicyviolationeventinit-originalpolicy\">originalPolicy ;\n DOMString /sourceFile\" data-link-type=\"dict-member\" data-type=\"DOMString \" href=\"#dom-securitypolicyviolationeventinit-sourcefile\">sourceFile ;\n long /lineNumber\" data-link-type=\"dict-member\" data-type=\"long \" href=\"#dom-securitypolicyviolationeventinit-linenumber\">lineNumber ;\n long /columnNumber\" data-link-type=\"dict-member\" data-type=\"long \" href=\"#dom-securitypolicyviolationeventinit-columnnumber\">columnNumber ;\n};\n
- \n \n
- documentURI, of type DOMString\n \n \n
- Refer to the
document-uriproperty of violation reports for a description of this property.\n \n \n - referrer, of type DOMString\n \n \n
- Refer to the
referrerproperty of violation reports for a description of this property.\n \n \n - blockedURI, of type DOMString\n \n \n
- Refer to the
blocked-uriproperty of violation reports for a description of this property.\n \n \n - violatedDirective, of type DOMString\n \n \n
- Refer to the
violated-directiveproperty of violation reports for a description of this property.\n \n \n - effectiveDirective, of type DOMString\n \n \n
- Refer to the
effective-directiveproperty of violation reports for a description of this property.\n \n \n - originalPolicy, of type DOMString\n \n \n
- Refer to the
original-policyproperty of violation reports for a description of this property.\n \n \n - sourceFile, of type DOMString\n \n \n
- Refer to the
source-fileproperty of violation reports for a description of this property.\n \n \n - lineNumber, of type long\n \n \n
- Refer to the
line-numberproperty of violation reports for a description of this property.\n \n \n - columnNumber, of type long\n \n \n
- Refer to the
column-numberproperty of violation reports for a description of this property.\n \n \n
6.3. Firing Violation Events
\n \n\n\nTo fire a violation event, the user agent MUST use an algorithm\n equivalent to the following:
\n \n\n \n- \n \n
- Let report object be the result of generating a\n violation report object.\n \n\n \n
- Queue a task to\n fire an event named\n
securitypolicyviolationusing the\nSecurityPolicyViolationEventinterface\n with the following initializations:\n\n \n- \n \n
blockedURIMUST be initialized to the value of\n report object’sblocked-urikey.\n \n\n \ndocumentURIMUST be initialized to the value of\n report object’sdocument-urikey.\n \n\n \neffectiveDirectiveMUST be initialized to the value of\n report object’seffective-directivekey.\n \n\n \noriginalPolicyMUST be initialized to the value of\n report object’soriginal-policykey.\n \n\n \nreferrerMUST be initialized to the value of\n report object’sreferrerkey.\n \n\n \nviolatedDirectiveMUST be initialized to the value of\n report object’sviolated-directivekey.\n \n\n \nsourceFileMUST be initialized to the value of\n report object’ssource-filekey.\n \n\n \nlineNumberMUST be initialized to the value of\n report object’sline-numberkey.\n \n\n \ncolumnNumberMUST be initialized to the value of\n report object’scolumn-numberkey.\n \n \n
The task source for these tasks\n is the Content Security Policy task source.
\n \n \n7. Directives
\n\n\nThis section describes the content security policy directives\n introduced in this specification. Directive names are case insensitive.
\n\n\nIn order to protect against Cross-Site Scripting (XSS), web\n application authors SHOULD include:
\n\n \n- \n \n
- both the
script-srcand\nobject-srcdirectives, or\n \n\n \n - include a
default-srcdirective, which covers both\n scripts and plugins.\n \n \n
In either case, authors SHOULD NOT include either\n 'unsafe-inline' or data: as valid sources in\n their policies. Both enable XSS attacks by allowing code to be included\n directly in the document itself; they are best avoided completely.
Redirects are another area of potential concern. Authors SHOULD NOT include\n 'unsafe-redirect' as valid sources in their policies. It makes\n it more difficult to reason about the complete set of resources that a policy\n allows, especially given the path behavior outlined in the\n §4.2.2.3 Paths and Redirects section.
7.1. base-uri
\n \n\n\n The base-uri directive restricts the URLs that can\n be used to specify the document base URL. The syntax for\n the name and value of the directive are described by the following ABNF\n grammar:
directive-name = \"base-uri\"\ndirective-value = source-list\n\n \n\n\n
The term allowed base URLs refers to the result of\n parsing the base-uri directive’s\n value as a source list.
Note: base-uri does not fall back to the default\n sources.
Step 4 of the algorithm defined in HTML5 to obtain a\n document’s base URL MUST be changed to:
\n \n\n \n- \n \n
- If the previous step was not successful, or the result of the\n previous step does not match\n the allowed base URLs for the protected resource, then the\n document base URL is fallback base URL.\n Otherwise, it is the result of the previous step.\n \n \n
7.2. child-src
\n \n\n\n The child-src directive governs the creation of\n nested browsing contexts as well as Worker execution\n contexts. The syntax for the name and value of the directive are described\n by the following ABNF grammar:
directive-name = \"child-src\"\ndirective-value = source-list\n\n \n\n\n
The term allowed child sources refers to the result of\n parsing the child-src\n directive’s value as a source list if a child-src\n directive is explicitly specified, and otherwise to the\n default sources.
7.2.1. Nested Browsing Contexts
\n \n\n\nTo enforce the child-src directive the user agent MUST\n enforce the frame-src directive.
7.2.2. Workers
\n \n\n\nWhenever the user agent fetches a URL while processing the\n Worker or SharedWorker constructors\n [WORKERS], the user agent MUST act as if there was a fatal network\n error and no resource was obtained, and report a violation\n if the URL does not match the\n allowed child sources for the protected resource.
7.3. connect-src
\n \n\n\n The connect-src directive restricts which URLs the\n protected resource can load using script interfaces. The syntax for the name\n and value of the directive are described by the following ABNF grammar:
directive-name = \"connect-src\"\ndirective-value = source-list\n\n \n\n\n
The term allowed connection targets refers to the result of\n parsing the connect-src\n directive’s value as a source list if the policy contains an\n explicit connect-src directive, or otherwise to the\n default sources.
Whenever the user agent fetches a URL in the course of one of the\n following activities, if the URL does not\n match the allowed connection\n targets for the protected resource, the user agent MUST act as\n if there was a fatal network error and no resource was obtained,\n and report a violation:
\n \n\n \n- \n \n \n
- Processing the
send()\n method of anXMLHttpRequestobject.\n \n\n \n - Processing the
WebSocket\n constructor.\n \n\n \n - Processing the
EventSource\n constructor.\n \n\n \n - Pinging an endpoint during hyperlink auditing.\n \n\n \n
- Sending a beacon via the
sendBeacon()method [BEACON]\n \n \n
7.3.1. Usage
\n \n\n\nThis section is not normative.
\n \n\n\nJavaScript offers a few mechanisms that directly connect to an\n external server to send or receive information. EventSource\n maintains an open HTTP connection to a server in order to receive push\n notifications, WebSockets open a bidirectional communication\n channel between your browser and a server, and XMLHttpRequest\n makes arbitrary HTTP requests on your behalf. These are powerful APIs that\n enable useful functionality, but also provide tempting avenues for data\n exfiltration.
The connect-src directive allows you to ensure that\n these sorts of connections are only opened to origins you trust.\n Sending a policy that defines a list of source expressions for this\n directive is straightforward. For example, to limit connections to\n only example.com, send the following header:
Content-Security-Policy: connect-src example.com\n \n\n\n
All of the following will fail with the preceding directive in\n place:
\n \n\n \n- \n \n
new WebSocket(\"wss://evil.com/\");\n \n \n(new XMLHttpRequest()).open(\"GET\", \"https://evil.com/\", true);\n \n \nnew EventSource(\"https://evil.com\");\n \n \n
7.4. default-src
\n \n\n\n The default-src directive sets a default\n source list for a number of directives. The syntax for the name and\n value of the directive are described by the following ABNF grammar:
directive-name = \"default-src\"\ndirective-value = source-list\n\n \n\n\n
Let the default sources be the result of\n parsing the default-src\n directive’s value as a source list if a default-src\n directive is explicitly specified, and otherwise the U+002A ASTERISK\n character (*).
To enforce the default-src directive, the user agent\n MUST enforce the following directives:
- \n \n
child-src\n \n \nconnect-src\n \n \nfont-src\n \n \nimg-src\n \n \nmedia-src\n \n \nobject-src\n \n \nscript-src\n \n \nstyle-src\n \n \n
If not specified explicitly in the policy, the directives listed\n above will use the default sources as their source list.
\n \n\n \n7.4.1. Usage
\n \n\n\nThis section is not normative.
\n \n\n\ndefault-src, as the name implies, serves as a default\n source list which the other source list-style directives will use as\n a fallback if they’re not otherwise explicitly set. That is, consider\n the following policy declaration:
Content-Security-Policy: default-src 'self'\n \n\n\n
Under this policy, fonts, frames, images, media, objects, scripts,\n and styles will all only load from the same origin as the protected\n resource, and connections will only be made to the same origin. Adding\n a more specific declaration to the policy would completely override\n the default source list for that resource type.
\n \n\n\nContent-Security-Policy: default-src 'self'; script-src example.com\n \n\n\n
Under this new policy, fonts, frames, and etc. continue to be load\n from the same origin, but scripts will only load from\n example.com. There’s no inheritance; the\n script-src directive sets the allowed sources of\n script, and the default list is not used for that resource type.
Given this behavior, one good way of building a policy for a site\n would be to begin with a default-src of\n 'none', and to build up a policy from there that contains\n only those resource types which are actually in use for the page you’d\n like to protect. If you don’t use webfonts, for instance, there’s no\n reason to specify a source list for font-src;\n specifying only those resource types a page uses ensures that the\n possible attack surface for that page remains as small as possible.
7.5. font-src
\n \n\n\n The font-src directive restricts from where the\n protected resource can load fonts. The syntax for the name and value\n of the directive are described by the following ABNF grammar:
directive-name = \"font-src\"\ndirective-value = source-list\n\n \n\n\n
The term allowed font sources refers to the result of\n parsing the font-src\n directive’s value as a source list if the policy contains an\n explicit font-src, or otherwise to the\n default sources.
Whenever the user agent fetches a URL in the course of one of the\n following activities, if the URL does not\n match the allowed font sources\n for the protected resource, the user agent MUST act as if there was\n a fatal network error and no resource was obtained, and report\n a violation:
\n \n\n \n- \n \n
- Requesting data for display in a font, such as when processing\n the <@font-face> Cascading Style Sheets (CSS) rule.\n \n \n
7.6. form-action
\n \n\n\n The form-action restricts which URLs can be used as\n the action of HTML form elements. The syntax for the name and value of\n the directive are described by the following ABNF grammar:
directive-name = \"form-action\"\ndirective-value = source-list\n\n \n\n\n
The term allowed form actions refers to the result of\n parsing the form-action\n directive’s value as a source list.
Whenever the user agent fetches a URL in the course of processing\n an HTML form element, if the URL does not\n match the allowed form actions for\n the protected resource, the user agent MUST act as if there was a\n fatal network error and no resource was obtained, and report a\n violation.
Note: form-action does not fall back to the default\n sources when the directive is not defined. That is, a policy that\n defines default-src 'none' but not\n form-action will still allow form submissions to any\n target.
7.7. frame-ancestors
\n \n\n\n The frame-ancestors directive indicates whether the\n user agent should allow embedding the resource using a frame,\n iframe, object, embed or applet element, or equivalent\n functionality in non-HTML resources. Resources can use this directive to\n avoid many UI Redressing [UIREDRESS] attacks by avoiding being embedded\n into potentially hostile contexts.
The syntax for the name and value of the directive are described by the\n following ABNF grammar:
\n \n\n \nancestor-source-list = [ ancestor-source *( 1*WSP ancestor-source ) ] / \"'none'\"\nancestor-source = scheme-source / host-source\n\ndirective-name = \"frame-ancestors\"\ndirective-value = ancestor-source-list\n\n \n\n\n
The term allowed frame ancestors refers to the result of\n parsing the frame-ancestors\n directive’s value as a source list. If a frame-ancestors\n directive is not explicitly included in the policy, then allowed frame\n ancestors is \"*\".
To enforce the frame-ancestors directive, whenever the\n user agent would load the protected resource into a nested browsing\n context, the user agent MUST perform the following steps:
- \n \n
- Let nestedContext be the nested browsing context into\n which the protected resource is being loaded.\n \n\n \n
- Let ancestorList be the list of all\n ancestors of nestedContext.\n \n\n \n
- For each ancestorContext in ancestorList:\n \n
- \n \n
- Let document be ancestorContext’s\n active document.\n \n\n \n
- If document’s URL does not\n match the allowed frame\n ancestors for the protected resource, the user agent MUST:\n \n
- \n \n
- Abort loading the protected resource.\n \n\n \n
- Take one of the following actions:\n\n \n
- \n \n
- \n Act as if it received an empty HTTP 200 response.\n \n \n \n
- \n Redirect the user to a friendly error page which provides\n the option of opening the blocked page in a new top-level\n browsing context.\n \n \n \n
- \n Parse a sandboxing directive using the\n empty string as the input and the newly created\n document’s forced sandboxing flag set as the\n output.\n \n \n\n \n
- Report a violation.\n \n\n \n
- Abort these steps.\n \n \n
Steps 3.2.2 and 3.2.3 ensure that the blocked frame appears to be a\n normal cross-origin document’s load. If these steps are ignored,\n leakage of a document’s policy state is possible.
\n \n\n\nThe frame-ancestors directive MUST be ignored\n when monitoring a policy, and when a contained in a\n policy defined via a meta element.
Note: frame-ancestors does not fall back to the\n default sources when the directive is not defined. That is, a policy\n that defines default-src 'none' but not\n frame-ancestors will still allow the resource to be framed from\n anywhere.
When generating a violation report for a frame-ancestors\n violation, the user agent MUST NOT include the value of the embedding\n ancestor as a blocked-uri value unless it is same-origin with\n the protected resource, as disclosing the value of cross-origin ancestors\n is a violation of the Same-Origin Policy.
7.7.1. \n Relation to X-Frame-Options\n
\n \n\n\n This directive is similar to the X-Frame-Options header that\n several user agents have implemented. The 'none' source\n expression is roughly equivalent to that header’s DENY,\n 'self' to SAMEORIGIN, and so on. The major\n difference is that many user agents implement SAMEORIGIN such\n that it only matches against the top-level document’s location. This\n directive checks each ancestor. If any ancestor doesn’t match, the load\n is cancelled. [RFC7034]
The frame-ancestors directive obsoletes the\n X-Frame-Options header. If a resource has both policies,\n the frame-ancestors policy SHOULD be enforced and the\n X-Frame-Options policy SHOULD be ignored.
7.7.2. Multiple Host Source Values
\n \n\n\nThis section is not normative.
\n \n\n\nMultiple source-list expressions are allowed in a single policy (in contrast\n to X-Frame-Options, which allows only one) to enable\n scenarios involving embedded application components that are multiple levels\n below the top-level browsing context.
Many common scenarios for permissioned embedding (e.g. embeddable payment,\n sharing or social apps) involve potentially many hundreds or thousands of\n valid source-list expressions, but it is strongly recommended\n against accommodating such scenarios with a static\n frame-ancestors directive listing multiple values. In such\n cases it is beneficial to generate this value dynamically, based on an\n HTTP Referer header or an explicitly passed-in value, to allow only the\n sources necessary for each given embedding of the resource.
Consider a service providing a payments application at\n https://payments/makeEmbedded. The service allows this resource\n to be embedded by both merchant Alice and merchant Bob, who compete with each\n other. Sending:
Content-Security-Policy: frame-ancestors https://alice https://bob\n\n \n\n\n
would allow Bob to re-frame Alice’s resource and create fraudulent clicks,\n perhaps discrediting Alice with her customers or the payments service. If the\n payments service used additional information (e.g. as part of a URL like\n https://payments/makeEmbedded?merchant=alice) to send\n individually-tailored headers listing only the source-list expressions\n needed by each merchant, this attack would be eliminated.
7.8. frame-src
\n \n\n\n The frame-src directive is deprecated.\n Authors who wish to govern nested browsing contexts SHOULD use the\n child-src directive instead.
The frame-src directive restricts from where the\n protected resource can embed frames. The syntax for the name\n and value of the directive are described by the following ABNF\n grammar:
directive-name = \"frame-src\"\ndirective-value = source-list\n\n \n\n\n
The term allowed frame sources refers to the result of\n parsing the frame-src\n directive’s value as a source list if the policy contains an\n explicit frame-src, or otherwise to the list of\n allowed child sources.
Whenever the user agent fetches a URL in the course of one of the\n following activities, if the URL does not\n match the allowed frame sources\n for the protected resource, the user agent MUST act as if there was a\n fatal network error and no resource was obtained, and report a\n violation:
\n \n\n \n- \n \n
- Requesting data for display in a nested browsing context in the\n protected resource created by an
iframeor aframeelement.\n\n \n - Navigated such a nested browsing context.\n \n \n
7.9. img-src
\n \n\n\n The img-src directive restricts from where the\n protected resource can load images. The syntax for the name and value\n of the directive are described by the following ABNF grammar:
directive-name = \"img-src\"\ndirective-value = source-list\n\n \n\n\n
The term allowed image sources refers to the result of\n parsing the img-src\n directive’s value as a source list if the policy contains an\n explicit img-src, or otherwise to the list of\n default sources.
Whenever the user agent fetches a URL in the course of one of the\n following activities, if the URL does not\n match the allowed image sources\n for the protected resource, the user agent MUST act as if there was a\n fatal network error and no resource was obtained, and report a\n violation:
\n \n\n \n- \n \n \n
- Requesting data for an image, such as when processing the\n
srcorsrcsetattributes of animgelement, the\nsrcattribute of aninputelement with a type of\nimage, theposterattribute of avideoelement,\n the url(), <image()> or <image-set()> values on any\n Cascading Style Sheets (CSS) property that is capable of loading an image\n [CSS4-IMAGES], or thehrefattribute of alinkelement\n with an image-relatedrelattribute, such asicon.\n \n \n
7.10. media-src
\n \n\n\n The media-src directive restricts from where the\n protected resource can load video, audio, and associated text tracks.\n The syntax for the name and value of the directive are described by the\n following ABNF grammar:
directive-name = \"media-src\"\ndirective-value = source-list\n\n \n\n\n
The term allowed media sources refers to the result of\n parsing the media-src\n directive’s value as a source list if the policy contains an\n explicit media-src, or otherwise to the list of\n default sources.
Whenever the user agent fetches a URL in the course of one of the\n following activities, if the URL does not\n match the allowed media sources\n for the protected resource, the user agent MUST act as if there was\n a fatal network error and no resource was obtained, and report\n a violation:
\n \n\n \n \n \n \n7.11. object-src
\n \n\n\n The object-src directive restricts from where\n the protected resource can load plugins. The syntax for the name and value\n of the directive are described by the following ABNF grammar:
directive-name = \"object-src\"\ndirective-value = source-list\n\n \n\n\n
The term allowed object sources refers to the result of\n parsing the object-src\n directive’s value as a source list if the policy contains an\n explicit object-src, or otherwise to the list of\n default sources.
Whenever the user agent fetches a URL in the course of one of the\n following activities, if the URL does not\n match the allowed object sources\n for the protected resource, the user agent MUST act as if there was a\n fatal network error and no resource was obtained, and report a\n violation:
\n \n\n \n- \n \n
- Requesting data for a plugin, such as when processing the\n
dataattribute of anobjectelement, thesrc\n attribute of anembedelement, or thecodeor\narchiveattributes of anappletelement.\n \n\n \n - Requesting data for display in a nested browsing context\n in the protected resource created by an
objector anembed\n element.\n \n\n \n - Navigating such a nested browsing context.\n \n \n
It is not required that the consumer of the element’s data be a\n plugin in order for the object-src directive to be\n enforced. Data for any object, embed, or applet element MUST\n match the allowed object sources in order to be fetched. This is true\n even when the element data is semantically equivalent to content which would\n otherwise be restricted by one of the other §7 Directives, such as an\n object element with a text/html MIME type.
Whenever the user agent would load a plugin without an associated\n URL (e.g., because the object element lacked a data\n attribute), if the protected resource’s URL does not\n match the allowed object sources\n for the protected resource, the user agent MUST NOT load the plugin.
7.12. plugin-types
\n \n\n\n The plugin-types directive restricts the set\n of plugins that can be invoked by the protected resource by limiting\n the types of resources that can be embedded. The syntax for the name\n and value of the directive are described by the following ABNF\n grammar:
directive-name = \"plugin-types\"\ndirective-value = media-type-list\n\n \n\n\n
The term allowed plugin media types refers to the result of\n parsing the plugin-types\n directive’s value as a media type list.
Whenever the user agent would instantiate a plugin\n to handle resource while enforcing the plugin-types\n directive, the user agent MUST instead act as though the plugin reported an\n error and report a violation if any of the following\n conditions hold:
- \n \n
- The plugin is embedded into the protected resource via an\n
objectorembedelement that does not explicitly\n declare a MIME type via atype\n attribute.\n \n\n \n - resource’s media type does not\n match the list of allowed\n plugin media types.\n \n\n \n
- The plugin is embedded into the protected resource via an\n
objectorembedelement, and the media type declared\n in the element’stypeattribute is not an ASCII\n case-insensitive match for the resource’s media\n type.\n \n\n \n - The plugin is embedded into the protected resource via an\n
appletelement, and resource’s media type is not an\n ASCII case-insensitive match for\napplication/x-java-applet.\n \n \n
Note: In any of these cases, acting as though the plugin reported an\n error will cause the user agent to display the fallback\n content.
\n \n\n\nWhenever the user agent creates a plugin document in a\n nested browsing context in the protected resource, if the user\n agent is enforcing any plugin-types directives for the\n protected resource, the user agent MUST enforce those\n plugin-types directives on the plugin document as well.
Whenever the user agent creates a plugin document in a\n nested browsing context in the protected resource, if the user\n agent is monitoring any plugin-types directives for the\n protected resource, the user agent MUST monitor those\n plugin-types directives on the plugin document as well.
7.12.1. Usage
\n \n\n\nThis section is not normative.
\n \n\n\nThe plugin-types directive whitelists a certain set\n of MIME types that can be embedded in a protected resource. For\n example, a site might want to ensure that PDF content loads, but that\n no other plugins can be instantiated. The following directive would\n satisfy that requirement:
Content-Security-Policy: plugin-types application/pdf\n \n\n\n
Resources embedded via an embed or\n object element delivered with an\n application/pdf content type would be rendered in the\n appropriate plugin; resources delivered with some other content type\n would be blocked. Multiple types can be specified, in any order. If the\n site decided to additionally allow Flash at some point in the future, it\n could do so with the following directive:
Content-Security-Policy: plugin-types application/pdf application/x-shockwave-flash\n \n\n\n
Note: Wildcards are not accepted in the plugin-types\n directive. Only the resource types explicitly listed in the directive\n will be allowed.
7.12.2. \n Predeclaration of expected media types\n
\n \n\n\nThis section is not normative.
\n \n\n\nEnforcing the plugin-types directive requires that\n object and embed\n elements declare the expected media type of the resource they include via\n the type attribute. If an author expects\n to load a PDF, she could specify this as follows:
<object data=\"resource\" type=\"application/pdf\"></object>\n \n\n\n
If resource isn’t actually a PDF file, it won’t\n load. This prevents certain types of attacks that rely on serving\n content that unexpectedly invokes a plugin other than that which the\n author intended.
\n \n\n\nNote: resource will not load in this scenario even\n if its media type is otherwise whitelisted: resources will only load\n when their media type is whitelisted and matches the\n declared type in their containing element.
\n \n \n7.13. report-uri
\n \n\n\n The report-uri directive specifies a URL to\n which the user agent sends reports about policy violation. The syntax\n for the name and value of the directive are described by the following\n ABNF grammar:
directive-name = \"report-uri\"\ndirective-value = uri-reference *( 1*WSP uri-reference )\nuri-reference = <URI-reference from RFC 3986>\n\n \n\n\n
The set of report URLs is the value of the\n report-uri directive, each resolved relative to the\n protected resource’s URL.
The process of sending violation reports to the URLs specified in\n this directive’s value is defined in this document’s\n §4.4 Reporting section.
\n \n\n\nNote: The report-uri directive will be ignored if contained\n within a meta\n element.
7.14. sandbox
\n \n\n\n The sandbox directive specifies an HTML\n sandbox policy that the user agent applies to the protected resource.\n The syntax for the name and value of the directive are described by\n the following ABNF grammar:
directive-name = \"sandbox\"\ndirective-value = \"\" / sandbox-token *( 1*WSP sandbox-token )\nsandbox-token = <token from RFC 7230>\n\n \n\n\n
When enforcing the sandbox directive, the user agent\n MUST parse a sandboxing directive using the\n directive-value as the input and protected\n resource’s forced sandboxing flag set\n as the output. [HTML5]
The sandbox directive will be ignored when monitoring\n a policy, and when contained in a policy defined via a\n meta element.\n Moreover, this directive has no effect when monitored, and has no\n reporting requirements.
7.14.1. Sandboxing and Workers
\n \n\n\nWhen delivered via an HTTP header, a Content Security Policy may indicate\n that sandboxing flags ought to be applied to a JavaScript execution\n environment that is not a Document. Of particular interest is the\n script content intended for use as a Worker, Shared Worker, or Service\n Worker. Many of the sandboxing flags do not apply to such environments, but\n allow-scripts and\n allow-same-origin have special\n requirements.
When a resource is loaded while executing the runs a\n Worker algorithm, the user agent MUST act as if there was\n a fatal network error and no resource could be obtained if either of the\n following conditions holds:
- \n \n
- \n The
sandboxdirective delivered with the resource\n does not contain the\n allow-scripts flag.\n \n \n \n - \n The
sandboxdirective delivered with the resource\n does not contain the\n allow-same-origin flag, and\n the creation of the new execution context requires it to be same-origin\n with its creating context.\n \n \n \n
7.14.2. Usage
\n \n\n\nThis section is not normative.
\n \n\n \nHTML5 defines a sandbox attribute for\n iframe elements, intended to allow web authors\n to reduce the risk of including potentially untrusted content by imposing\n restrictions on that content’s abilities. When the attribute is set,\n the content is forced into a unique origin, prevented from submitting\n forms, running script, creating or navigating other browsing contexts,\n and prevented from running plugins. These restrictions can be loosened\n by setting certain flags as the attribute’s value.\n\n
The sandbox directive allows any resource, framed or\n not, to ask for the same sorts of restrictions to be applied to\n itself.
For example, a message board or email system might provide\n downloads of arbitrary attachments provided by other users. Attacks\n that rely on tricking a client into rendering one of these attachments\n could be mitigated by requesting that resources only be rendered in a\n very restrictive sandbox. Sending the sandbox directive\n with an empty value establishes such an environment:
Content-Security-Policy: sandbox\n \n\n\n
More trusted resources might be allowed to run in an environment\n with fewer restrictions by adding allow-* flags to the\n directive’s value. For example, you can allow a page that you trust\n to run script, while ensuring that it isn’t treated as same-origin\n with the rest of your site. This can be accomplished by sending the\n sandbox directive with the\n allow-scripts flag:
Content-Security-Policy: sandbox allow-scripts\n \n\n\n
The set of flags available to the CSP directive should match those\n available to the iframe attribute.\n Currently, those include:
- \n \n
allow-forms\n \n \nallow-pointer-lock\n \n \nallow-popups\n \n \nallow-same-origin\n \n \nallow-scripts, and\n \n \nallow-top-navigation\n \n \n
Note: Like the rest of Content Security Policy, the sandbox\n directive is meant as a defense-in-depth. Web authors would be well-served\n to use it in addition to standard sniffing-mitigation and\n privilege-reduction techniques.
7.15. script-src
\n \n\n\n The script-src directive restricts which scripts the\n protected resource can execute. The directive also controls other resources,\n such as XSLT style sheets [XSLT], which can cause the user agent to\n execute script. The syntax for the name and value of the directive are\n described by the following ABNF grammar:
directive-name = \"script-src\"\ndirective-value = source-list\n\n \n\n\n
The term allowed script sources refers to the result of\n parsing the script-src\n directive’s value as a source list if the policy contains an\n explicit script-src, or otherwise to the default\n sources.
If 'unsafe-inline' is not in the\n list of allowed script sources, or if at least one\n nonce-source or hash-source is\n present in the list of allowed script sources:
- \n \n
- Whenever the user agent would execute an inline script from a\n
scriptelement that lacks a valid nonce\n and lacks a valid hash for the allowed script\n sources, instead the user agent MUST NOT execute script, and\n MUST report a violation.\n \n\n \n - Whenever the user agent would execute an inline script from an\n inline event handler, instead the user agent MUST NOT execute script,\n and MUST report a violation.\n \n\n \n
- Whenever the user agent would execute script contained in a\n
javascriptURL, instead the user agent MUST NOT execute\n the script, and MUST report a violation.\n \n \n
If 'unsafe-eval' is not in allowed script\n sources:
- \n \n
- Instead of evaluating their arguments, both operator\n
evaland functioneval[ECMA-262]\n MUST throw anEvalErrorexception.\n \n\n \n - When called as a constructor, the function
Function\n [ECMA-262] MUST throw anEvalErrorexception.\n \n\n \n - When called with a first argument that is not callable (a\n string, for example), the\n
setTimeout()function MUST\n return zero without creating a timer.\n \n\n \n - When called with a first argument that is not callable (a\n string, for example), the\n
setInterval()function MUST\n return zero without creating a timer.\n \n \n
Whenever the user agent fetches a URL (including when following\n redirects) in the course of one of the following activities, if the URL does\n not match the allowed script\n sources for the protected resource, the user agent MUST act as if\n there was a fatal network error and no resource was obtained, and\n report a violation:
\n \n\n \n- \n \n
- Requesting a script while processing the
srcattribute of\n ascriptelement that lacks a valid nonce for the allowed\n script sources.\n \n\n \n - Requesting a script while invoking the
importScripts\n method on a WorkerGlobalScope object. [WORKERS]\n \n\n \n - Requesting an HTML component, such as\n when processing the
hrefattribute of alink\n element with arelattribute containing the token\nimport. [HTML-IMPORTS]\n \n\n \n - Requesting an Extensible Stylesheet Language Transformations\n (XSLT) [XSLT], such as when processing the\n
<?xml-stylesheet?>processing directive in an XML\n document [XML11], thehrefattributes\n on<xsl:include>and<xsl:import>\n elements.\n \n \n
7.15.1. \n Nonce usage for script elements\n
\n \n\n\n This section is not normative.
\n \n\n\nThe script-src directive lets developers specify\n exactly which script elements on a page were intentionally included\n for execution. Ideally, developers would avoid inline script entirely\n and whitelist scripts by URL. However, in some cases, removing inline\n scripts can be difficult or impossible. For those cases, developers can\n whitelist scripts using a randomly generated nonce.
Usage is straightforward. For each request, the server\n generates a unique value at random, and includes it in the\n Content-Security-Policy header:
Content-Security-Policy: default-src 'self';\n script-src 'self' https://example.com 'nonce-$RANDOM'\n\n \n\n\n
This same value is then applied as a nonce attribute\n to each script element that ought to be\n executed. For example, if the server generated the random value\n Nc3n83cnSAd3wc3Sasdfn939hc3, the server would send the\n following policy:
Content-Security-Policy: default-src 'self';\n script-src 'self' https://example.com 'nonce-Nc3n83cnSAd3wc3Sasdfn939hc3'\n\n \n\n\n
Script elements can then execute either because their src URLs\n are whitelisted or because they have a valid nonce:
<script>\nalert(\"Blocked because the policy doesn’t have 'unsafe-inline'.\")\n</script>\n\n<script nonce=\"EDNnf03nceIOfn39fn3e9h3sdfa\">\nalert(\"Still blocked because nonce is wrong.\")\n</script>\n\n<script nonce=\"Nc3n83cnSAd3wc3Sasdfn939hc3\">\nalert(\"Allowed because nonce is valid.\")\n</script>\n\n<script src=\"https://example.com/allowed-because-of-src.js\"></script>\n\n<script nonce=\"EDNnf03nceIOfn39fn3e9h3sdfa\"\n src=\"https://elsewhere.com/blocked-because-nonce-is-wrong.js\"></script>\n\n<script nonce=\"Nc3n83cnSAd3wc3Sasdfn939hc3\"\n src=\"https://elsewhere.com/allowed-because-nonce-is-valid.js\"></script>\n\n \n\n\n
Note that the nonce’s value is not a hash or signature\n that verifies the contents of the script resources. It’s quite simply\n a random string that informs the user agent which scripts were\n intentionally included in the page.
\n \n\n\nScript elements with the proper nonce execute, regardless of\n whether they’re inline or external. Script elements without the\n proper nonce don’t execute unless their URLs are whitelisted.\n Even if an attacker is able to inject markup into the protected\n resource, the attack will be blocked by the attacker’s inability\n to guess the random value.
\n \n \n7.15.2. \n Hash usage for script elements\n
\n \n\n\n This section is not normative.
\n \n\n\nThe script-src directive lets developers whitelist a\n particular inline script by specifying its hash as an allowed source\n of script.
Usage is straightforward. The server computes the hash of a\n particular script block’s contents, and includes the base64 encoding\n of that value in the Content-Security-Policy header:
Content-Security-Policy: default-src 'self';\n script-src 'self' https://example.com 'sha256-base64 encoded hash'\n\n \n\n\n
Each inline script block’s contents are hashed, and compared against\n the whitelisted value. If there’s a match, the script is executed. For\n example, the SHA-256 digest of alert('Hello, world.'); is\n qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=.
openssl program. For example:\n\n \n echo -n \"alert('Hello, world.');\" | openssl dgst -sha256 -binary | openssl enc -base64\n\n \n \n If the server sent the following header:
\n \n\n \nContent-Security-Policy: script-src 'sha512-YWIzOWNiNzJjNDRlYzc4MTgwMDhmZDlkOWI0NTAyMjgyY2MyMWJlMWUyNjc1ODJlYWJhNjU5MGU4NmZmNGU3OAo='\n\n \n\n\n
Then the following script tag would result in script execution:
\n \n\n \n<script>alert('Hello, world.');</script>\n\n \n\n\n Whitespace is significant. The following scripts blocks would not hash to\n the same value, and would therefore not execute:
\n \n\n \n<script> alert('Hello, world.');</script>\n<script>alert('Hello, world.'); </script>\n<script> alert('Hello, world.'); </script>\n<script>\nalert('Hello, world.');\n</script>\n\n \n\n\n Note also that the hash applies only to inline script. An\n externalized script containing the value\n alert('Hello, world.'); would not execute if its\n origin was not whitelisted as a valid source of script.
7.16. style-src
\n \n\n\n The style-src directive restricts which styles the\n user may applies to the protected resource. The syntax for the name and\n value of the directive are described by the following ABNF grammar:
directive-name = \"style-src\"\ndirective-value = source-list\n\n \n\n\n
The term allowed style sources refers to the result of\n parsing the style-src\n directive’s value as a source list if the policy contains an\n explicit style-src, or otherwise to the default sources.
If 'unsafe-inline' is not in the\n list of allowed style sources, or if at least one\n nonce-source or hash-source\n is present in the list of allowed style sources:
- \n \n
- Whenever the user agent would apply style from a\n
styleelement that lacks a\n valid nonce and lacks a valid hash for the\n allowed style sources, instead the user agentMUST\n ignore the style, and MUST report a violation.\n \n\n \n - Whenever the user agent would apply style from a\n
styleattribute, instead the user agent\nMUSTignore the style, and MUST report a\n violation.\n \n \n
Note: These restrictions on inline do not prevent the user agent\n from applying style from an external stylesheet (e.g., found via\n <link rel=\"stylesheet\" ...>).
If 'unsafe-eval' is not in allowed style\n sources, then:
- \n \n
- Whenever the user agent would invoke the Cascading Style Sheets\n Object Model algorithms\n insert a CSS rule, parse a CSS rule,\n parse a CSS declaration block, or\n parse a group of selectors\n instead the user agent MUST throw a SecurityError\n exception and terminate the algorithm. This would include,\n for example, all invocations of CSSOM’s various
cssText\n setters andinsertRulemethods. [CSSOM] [HTML5]\n \n \n
Whenever the user agent fetches a URL in the course of one of the\n following activities, if the URL does not\n match the allowed style sources\n for the protected resource, the user agent MUST act as if there was\n a fatal network error and no resource was obtained, and report\n a violation:
\n \n\n \n- \n \n
- \n Requesting an external stylesheet when processing the\n href of a link element\n whose rel attribute contains the token\n
stylesheet.\n \n \n \n - \n Requesting an external stylesheet when processing the <@import>\n directive.\n \n \n \n
- \n Requesting an external stylesheet when processing a
Link\n HTTP response header field [RFC5988].\n\n\nNote: As this stylesheet might be prefetched before a
\n \n \n \n \nDocument\n actually exists, user agents will need to carefully consider how to\n instantiate a meaningful policy against which to compare this\n request. See §10.1 Processing Complications for more detail.
Note: The style-src directive does not restrict the\n use of XSLT. XSLT is restricted by the script-src\n directive because the security consequences of including an untrusted\n XSLT stylesheet are similar to those incurred by including an\n untrusted script.
7.16.1. \n Nonce usage for style elements\n
\n \n\n\n This section is not normative.
\n \n\n\nSee the script-src\n nonce usage information for detail; the application of nonces\n to style elements is similar enough to avoid\n repetition here.
7.16.2. \n Hash usage for style elements\n
\n \n\n\n This section is not normative.
\n \n\n\nSee the script-src\n hash usage information for detail; the application of hashes\n to style elements is similar enough to avoid\n repetition here.
8. Examples
\n\n \n8.1. Sample Policy Definitions
\n \n\n\nThis section provides some sample use cases and supporting policies.
\n \n\n \nContent-Security-Policy: default-src 'self'\n \n \n
Content-Security-Policy:\n default-src 'self'; img-src *;\n object-src media1.example.com media2.example.com *.cdn.example.com;\n script-src trustedscripts.example.com\n\n \n \n
Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval'\n \n\n\n
This policy allows inline content (such as inline\n script elements), use of eval,\n and loading resources over https. Note: This policy does\n not provide any protection from cross-site scripting vulnerabilities.
script elements\n wishes to ensure that script is only executed from its own origin, and those\n elements it intentionally inserted inline:\n\n\n Content-Security-Policy: script-src 'self' 'nonce-$RANDOM';\n \n\n\n
The inline script elements would then only\n execute if they contained a matching\n nonce attribute:
<script nonce=\"$RANDOM\">...</script>\n \n \n
8.2. Sample Violation Report
\n \n\n\nThis section contains an example violation report the user agent\n might sent to a server when the protected resource violations a sample\n policy.
\n \n\n\nIn the following example, the user agent rendered a representation\n of the resource http://example.org/page.html with the\n following policy:
default-src 'self'; report-uri http://example.org/csp-report.cgi\n \n\n\n
The protected resource loaded an image from\n http://evil.example.com/image.png, violating the\n policy.
{\n \"csp-report\": {\n \"document-uri\": \"http://example.org/page.html\",\n \"referrer\": \"http://evil.example.com/haxor.html\",\n \"blocked-uri\": \"http://evil.example.com/image.png\",\n \"violated-directive\": \"default-src 'self'\",\n \"effective-directive\": \"img-src\",\n \"original-policy\": \"default-src 'self'; report-uri http://example.org/csp-report.cgi\"\n }\n}\n\n \n \n 9. Security Considerations
\n \n9.1. Cascading Style Sheet (CSS) Parsing
\n \n\n\nThe style-src directive restricts the locations from\n which the protected resource can load styles. However, if the user agent uses a\n lax CSS parsing algorithm, an attacker might be able to trick the user\n agent into accepting malicious \"stylesheets\" hosted by an otherwise\n trustworthy origin.
These attacks are similar to the CSS\n cross-origin data leakage attack described by Chris Evans in 2009.\n User agents SHOULD defend against both attacks using the same\n mechanism: stricter CSS parsing rules for style sheets with improper\n MIME types.
\n \n \n9.2. Violation Reports
\n \n\n\nThe violation reporting mechanism in this document has been\n designed to mitigate the risk that a malicious web site could use\n violation reports to probe the behavior of other servers. For example,\n consider a malicious web site that white lists https://example.com\n as a source of images. If the malicious site attempts to load\n https://example.com/login as an image, and the\n example.com server redirects to an identity provider (e.g.,\n identityprovider.example.net), CSP will block the request.\n If violation reports contained the full blocked URL, the violation\n report might contain sensitive information contained in the redirected URL,\n such as session identifiers or purported identities. For this reason, the\n user agent includes only the origin of the blocked URL.
10. Implementation Considerations
\n\n\nThe Content-Security-Policy header is an end-to-end\n header. It is processed and enforced at the client and, therefore,\n SHOULD NOT be modified or removed by proxies or other intermediaries not\n in the same administrative domain as the resource.
The originating administrative domain for a resource might wish to\n apply a Content-Security-Policy header outside of the\n immediate context of an application. For example, a large organization\n might have many resources and applications managed by different\n individuals or teams but all subject to a uniform organizational\n standard. In such situations, a Content-Security-Policy\n header might be added or combined with an existing one at a network-edge\n security gateway device or web application firewall. To enforce multiple\n policies, the administrator SHOULD combine the policy into a single header.\n An administrator might wish to use different combination algorithms\n depending on his or her intended semantics.
One sensible policy combination algorithm is to start by allowing a\n default set of sources and then letting individual upstream resource\n owners expand the set of allowed sources by including additional origins.\n In this approach, the resultant policy is the union of all allowed\n origins in the input policies.
\n\n\nAnother sensible policy combination algorithm is to intersect the\n given policies. This approach enforces that content comes from a certain\n whitelist of origins, for example, preventing developers from including\n third-party scripts or content in violation of organizational standards\n and practices. In this approach, the combination algorithm forms the\n combined policy by removing disallowed hosts from the policies supplied\n by upstream resource owners.
\n\n\nInteractions between the default-src and other directives\n SHOULD be given special consideration when combining policies. If none\n of the policies contains a default-src directive, adding new\n src directives results in a more restrictive policy. However, if one or\n more of the input policies contain a default-src directive,\n adding new src directives might result in a less restrictive policy, for\n example, if the more specific directive contains a more permissive set of\n allowed origins.
Using a more restrictive policy than the input policy authored by the\n resource owner might prevent the resource from rendering or operating as\n intended.
\n\n\nNote: Migration to HTTPS from HTTP\n may require updates to the policy in order to keep things running as\n before. Source expressions like http://example.com do\n not match HTTPS resources. For example,\n administrators SHOULD carefully examine existing policies before rolling\n out HTTP Strict Transport Security\n headers for an application. [RFC6797]
Content-Security-Policy: frame-ancestors https://example.com/ \nContent-Security-Policy: default-src https:; report-uri https://example.com/\n\n \n\n\n
would send violation reports for http resources, but would not\n send violation reports for frame-ancestors violations.\n Note also that combining them via ',' into the single header
Content-Security-Policy: frame-ancestors https://example.com/, default-src https:; report-uri https://example.com/\n\n \n\n\n
would have the same effect, as the comma splits the header during parsing.
\n \n \n10.1. Processing Complications
\n\n\nMany user agents implement some form of optimistic resource fetching algorithm\n to speed up page loads. In implementing these features, user agents MUST\n ensure that these optimizations do not alter the behavior of the page’s\n security policy.
\n\n\nHere, we’ll note a few potential complications that could cause bugs in\n implementations:
\n\n \n- \n \n
- \n The frame-ancestor directive MUST take effect before a document is\n loaded into a nested browsing context, and certainly before script\n is potentially executed. One way to approach this constraint is to perform\n the ancestor check defined in §7.7 frame-ancestors while parsing\n the document’s headers. This might mean that no document object is\n available at all, which can complicate checks against
'self',\n and scheme- or port-relative source expressions.\n \n \n \n - \n Likewise, the
LinkHTTP response header could generate\n requests for stylesheet resources before a document is available. User\n agents MUST ensure that any policy contained in the response headers is\n parsed and effective before these requests are generated. For\n example, a response returning the following headers:\n\n \nContent-Security-Policy: style-src 'none'\nLink: <awesome.css>; rel=stylesheet\n
\n \n\n\nMUST have the same behavior as a response returning the following headers:
\n \n\n \nLink: <awesome.css>; rel=stylesheet\nContent-Security-Policy: style-src 'none'\n
\n \n\n\nnamely, both must block requests for the stylesheet. To fulfil this\n requirement user agents MUST wait until all headers have been processed\n before beginning to prefetch resources.
\n \n \n \n \n
11. IANA Considerations
\n\n\nThe permanent message header field registry should be updated\n with the following registrations: [RFC3864]
\n\n \n11.1. Content-Security-Policy
\n \n\n \n- \n \n
- Header field name\n \n \n
- Content-Security-Policy\n \n\n \n
- Applicable protocol\n \n \n
- http\n \n\n \n
- Status\n \n \n
- standard\n \n\n \n
- Author/Change controller\n \n \n
- W3C\n \n\n \n
- Specification document\n \n \n
- This specification (See
Content-Security-Policy\n Header Field)\n \n \n
11.2. Content-Security-Policy-Report-Only
\n \n\n \n- \n \n
- Header field name\n \n \n
- Content-Security-Policy-Report-Only\n \n\n \n
- Applicable protocol\n \n \n
- http\n \n\n \n
- Status\n \n \n
- standard\n \n\n \n
- Author/Change controller\n \n \n
- W3C\n \n\n \n
- Specification document\n \n \n
- This specification (See\n
Content-Security-Policy-Report-OnlyHeader Field)\n \n \n
11.3. CSP
\n \n\n \n- \n \n
- Header field name\n \n \n
- CSP\n \n\n \n
- Applicable protocol\n \n \n
- http\n \n\n \n
- Status\n \n \n
- standard\n \n\n \n
- Author/Change controller\n \n \n
- W3C\n \n\n \n
- Specification document\n \n \n
- This specification (See §3.4 The CSP HTTP Request Header)\n \n \n
12. Acknowledgements
\n\n\nIn addition to the documents in the W3C Web Application Security working\n group, the work on this document is also informed by the work of the\n IETF websec working group,\n particularly that working group’s requirements document:\n draft-hodges-websec-framework-reqs.
\n\n\nA portion of the frame-ancestors directive was\n originally developed as X-Frame-Options. [RFC7034]
Brian Smith, Neil Matatall, Anne van Kesteren, and Sigbjørn Vik provided\n particularly insightful feedback to keep this specification sane.
\n