Copyright © 2019 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
+Copyright © 2020 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
This document defines a mechanism by which web developers can control the -resources which a particular page can fetch or execute, as well as a number -of security-relevant policy decisions.
+ resources which a particular page can fetch or execute, as well as a number + of security-relevant policy decisions.The (archived) public mailing list public-webappsec@w3.org (see instructions) +
The (archived) public mailing list public-webappsec@w3.org (see instructions) is preferred for discussion of this specification. When sending e-mail, - please put the text “csp3” in the subject, + please put the text “CSP3” in the subject, preferably like this: - “[csp3] …summary of comment…”
+ “[CSP3] …summary of comment…”This document was produced by the Web Application Security Working Group.
This document was produced by a group operating under - the 5 February 2004 W3C Patent Policy. + the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. - An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
-This document is governed by the 1 March 2017 W3C Process Document.
+ An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy. +This document is governed by the 15 September 2020 W3C Process Document.
The following features are at-risk, and may be dropped during the CR period:
“At-risk” is a W3C Process term-of-art, and does not necessarily imply that the feature is in danger of being dropped or delayed. It means that the WG believes the feature may have difficulty being interoperably implemented in a timely manner, and marking it as such allows the WG to drop the feature if necessary when transitioning to the Proposed Rec stage, without having to publish a new Candidate Rec without the feature first.
CSP list
This section is not normative.
-This document defines Content Security Policy (CSP), a tool +
This document defines Content Security Policy (CSP), a tool which developers can use to lock down their applications in various ways, mitigating the risk of content injection vulnerabilities such as cross-site scripting, and reducing the privilege with which their applications execute.
@@ -1882,8 +2343,8 @@Content Security Policy aims to do to a few related things:
Mitigate the risk of content-injection attacks by giving developers fairly granular control over
-Mitigate the risk of attacks which require a resource to be embedded in a malicious context (the "Pixel Perfect" attack described in [TIMING], for example) by giving developers granular control over the origins which can embed a given resource.
-Provide a policy framework which allows developers to reduce the privilege of their applications.
-Provide a reporting mechanism which allows developers to detect flaws being exploited in the wild.
The specification has been rewritten from the ground up in terms of the [FETCH] specification, which should make it simpler to integrate CSP’s requirements and restrictions with other specifications (and with Service Workers in particular).
-The child-src
model has been substantially altered:
The frame-src
directive, which was deprecated in CSP Level
2, has been undeprecated, but continues to defer to child-src
if
not present (which defers to default-src
in turn).
A worker-src
directive has been added, deferring to child-src
if not present (which likewise defers to script-src
and
eventually default-src
).
Dedicated workers now always inherit their creator’s policy.
The URL matching algorithm now treats insecure schemes and ports as
matching their secure variants. That is, the source expression http://example.com:80
will match both http://example.com:80
and https://example.com:443
.
Likewise, 'self'
now matches https:
and wss:
variants of the page’s
origin, even on pages whose scheme is http
.
Violation reports generated from inline script or style will now report
"inline
" as the blocked resource. Likewise, blocked eval()
execution
will report "eval
" as the blocked resource.
The manifest-src
directive has been added.
The report-uri
directive is deprecated in favor of the new report-to
directive, which relies on [REPORTING] as infrastructure.
The 'strict-dynamic'
source expression will now allow script which
- executes on a page to load more script via non-"parser-inserted" script
elements. Details are in §8.2 Usage of "'strict-dynamic'".
script
elements. Details are in § 8.2 Usage of "'strict-dynamic'".
+ The 'unsafe-hashes'
source expression will now allow event
handlers, style attributes and javascript:
navigation targets to match
- hashes. Details in §8.3 Usage of "'unsafe-hashes'".
The source expression matching has been changed to require explicit presence of any non-network scheme, rather than local scheme, unless that non-network scheme is the same as the scheme of protected resource, - as described in §6.6.2.6 Does url match expression in origin with redirect count?.
-Hash-based source expressions may now match external scripts if the script
element that triggers the request specifies a set of integrity
- metadata which is listed in the current policy. Details in §8.4 Allowing external JavaScript via hashes.
The navigate-to
directive gives a resource control over the endpoints
to which it can initiate navigation.
Reports generated for inline violations will contain a sample attribute if the relevant directive contains the 'report-sample'
expression.
The following definitions are used to improve readability of other definitions in this document.
-optional-ascii-whitespace = *( %x09 / %x0A / %x0C / %x0D / %x20 ) -required-ascii-whitespace = 1*( %x09 / %x0A / %x0C / %x0D / %x20 ) -; These productions match the definition of ASCII whitespace from the INFRA standard. +optional-ascii-whitespace = *( %x09 / %x0A / %x0C / %x0D / %x20 ) +required-ascii-whitespace = 1*( %x09 / %x0A / %x0C / %x0D / %x20 ) +; These productions match the definition of ASCII whitespace from the INFRA standard.2.2. Policies
-A policy defines allowed - and restricted behaviors, and may be applied to a
-Document
,WorkerGlobalScope
, orWorkletGlobalScope
as described in §4.2.2 Initialize a global object’s CSP list and in §4.2.1 Initialize a Document's CSP list.Each policy has an associated directive set, which is an ordered +
A policy defines allowed + and restricted behaviors, and may be applied to a
+Document
,WorkerGlobalScope
, orWorkletGlobalScope
as described in § 4.2.2 Initialize a global object’s CSP list and in § 4.2.1 Initialize a Document's CSP list.Each policy has an associated directive set, which is an ordered set of directives that define the policy’s implications when applied.
-Each policy has an associated disposition, which is either +
Each policy has an associated disposition, which is either "
-enforce
" or "report
".Each policy has an associated source, which is either "
header
" +Each policy has an associated source, which is either "
-header
" or "meta
".Each policy has an associated self-origin, which - is an origin that is used when matching the
+'self'
keyword.Each policy has an associated self-origin, which + is an origin that is used when matching the
'self'
keyword.Note: This is needed to facilitate the
-'self'
checks of local scheme documents/workers that have inherited their policy but have an opaque origin. Most of the time this will simply be the environment settings object’s origin. - The §4.2.1 Initialize a Document's CSP list algorithm describes situations in which + The § 4.2.1 Initialize a Document's CSP list algorithm describes situations in which a policy is inherited.Multiple policies can be applied to a single resource, and are collected into a list of policies known as a CSP list.
-A CSP list contains a header-delivered Content Security Policy if it contains a policy whose source is "
-header
".A serialized CSP is an ASCII string consisting of a semicolon-delimited +
Multiple policies can be applied to a single resource, and are collected into a list of policies known as a CSP list.
+A CSP list contains a header-delivered Content Security Policy if it contains a policy whose source is "
+header
".A serialized CSP is an ASCII string consisting of a semicolon-delimited series of serialized directives, adhering to the following ABNF grammar [RFC5234]:
-serialized-policy = +value.serialized-policy = serialized-directive *( optional-ascii-whitespace ";" [ optional-ascii-whitespace serialized-directive ] )-A serialized CSP list is an ASCII string consisting of a comma-delimited +
A serialized CSP list is an ASCII string consisting of a comma-delimited series of serialized CSPs, adhering to the following ABNF grammar [RFC5234]:
-serialized-policy-list = 1#serialized-policy +serialized-policy-list = 1#serialized-policy ; The '#' rule is the one defined in section 7 of RFC 7230 ; but it incorporates the modifications specified ; in section 2.1 of this document.2.2.1. Parse a serialized CSP
-To parse a serialized CSP, given a serialized CSP (serialized), a source (source), and a disposition (disposition), execute the +
To parse a serialized CSP, given a serialized CSP (serialized), a source (source), and a disposition (disposition), execute the following steps.
This algorithm returns a Content Security Policy object. If serialized could not be parsed, the object’s directive set will be empty.
-
- +
Let policy be a new policy with an empty directive set, a source of source, and a disposition of disposition.
-- +
For each token returned by strictly splitting serialized on the U+003B SEMICOLON character (
;
):-
-- +
Strip leading and trailing ASCII whitespace from token.
-- +
If token is an empty string, continue.
-- +
Let directive name be the result of collecting a sequence of code points from token which are not ASCII whitespace.
-- +
Set directive name to be the result of running ASCII lowercase on directive name.
Note: Directive names are case-insensitive, that is:
-script-SRC 'none'
andScRiPt-sRc 'none'
are equivalent.- +
If policy’s directive set contains a directive whose name is directive name, continue.
Note: In this case, the user agent SHOULD notify developers that a duplicate directive was ignored. A console warning might be appropriate, for example.
-- +
Let directive value be the result of splitting token on ASCII whitespace.
-- +
Let directive be a new directive whose name is directive name, and value is directive value.
-- +
Append directive to policy’s directive set.
- +
Return policy.
2.2.2. Parse a serialized CSP list
-To parse a serialized CSP list, given a serialized CSP list (list), a source (source), and a disposition (disposition), execute the following +
To parse a serialized CSP list, given a serialized CSP list (list), a source (source), and a disposition (disposition), execute the following steps.
This algorithm returns a list of Content Security Policy objects. If list cannot be parsed, the returned list will be empty.
-
- +
Let policies be an empty list.
-- +
For each token returned by splitting list on commas:
-
-- +
Let policy be the result of parsing token, with a source of source, and disposition of disposition.
-- +
If policy’s directive set is empty, continue.
-- +
Append policy to policies.
- +
Return policies.
2.3. Directives
-Each policy contains an ordered set of directives (its directive set), each of which controls a specific behavior. The directives - defined in this document are described in detail in §6 Content Security Policy Directives.
-Each directive is a name / value pair. The name is a +
Each policy contains an ordered set of directives (its directive set), each of which controls a specific behavior. The directives + defined in this document are described in detail in § 6 Content Security Policy Directives.
+Each directive is a name / value pair. The name is a non-empty string, and the value is a set of non-empty strings. The value MAY be empty.
-A serialized directive is an ASCII string, consisting of one or more +
A serialized directive is an ASCII string, consisting of one or more whitespace-delimited tokens, and adhering to the following ABNF [RFC5234]:
-serialized-directive = directive-name [ required-ascii-whitespace directive-value ] -directive-name = 1*( ALPHA / DIGIT / "-" ) -directive-value = *( required-ascii-whitespace / ( %x21-%x2B / %x2D-%x3A / %x3C-%x7E ) ) +serialized-directive = directive-name [ required-ascii-whitespace directive-value ] +directive-name = 1*( ALPHA / DIGIT / "-" ) +directive-value = *( required-ascii-whitespace / ( %x21-%x2B / %x2D-%x3A / %x3C-%x7E ) ) ; Directive values may contain whitespace and VCHAR characters, ; excluding ";" and ",". The second half of the definition ; above represents all VCHAR characters (%x21-%x7E) @@ -2099,103 +2560,103 @@
Directives have a number of associated algorithms:
-
- -
A pre-request check, which takes a request and a policy as an argument, and is executed - during §4.1.3 Should request be blocked by Content Security Policy?. This algorithm returns "
Allowed
" unless +- +
A pre-request check, which takes a request and a policy as an argument, and is executed + during § 4.1.3 Should request be blocked by Content Security Policy?. This algorithm returns "
-Allowed
" unless otherwise specified.- -
A post-request check, which takes a request, a response, and a policy as arguments, - and is executed during §4.1.4 Should response to request be blocked by Content Security Policy?. This algorithm returns +
- +
A post-request check, which takes a request, a response, and a policy as arguments, + and is executed during § 4.1.4 Should response to request be blocked by Content Security Policy?. This algorithm returns "
-Allowed
" unless otherwise specified.- -
A response check, which takes a request, a response, and a policy as arguments, - and is executed during §4.1.4 Should response to request be blocked by Content Security Policy?. This algorithm returns +
- +
A response check, which takes a request, a response, and a policy as arguments, + and is executed during § 4.1.4 Should response to request be blocked by Content Security Policy?. This algorithm returns "
-Allowed
" unless otherwise specified.- -
An inline check, which takes an
Element
a +- +
An inline check, which takes an
-Element
, a type string, a policy, and a source string as arguments, - and is executed during §4.2.4 Should element’s inline type behavior be blocked by Content Security Policy? and during §4.2.5 Should navigation request of type from source in target be blocked + and is executed during § 4.2.4 Should element’s inline type behavior be blocked by Content Security Policy? and during § 4.2.5 Should navigation request of type be blocked by Content Security Policy? forjavascript:
requests. This algorithm returns "Allowed
" unless otherwise specified.- -
An initialization, which takes a
Document
or global object, a response, and a policy as arguments. This algorithm is executed during §4.2.1 Initialize a Document's CSP list, +- +
An initialization, which takes a
-Document
or global object, a response, and a policy as arguments. This algorithm is executed during § 4.2.1 Initialize a Document's CSP list, and has no effect unless otherwise specified.- -
A pre-navigation check, which takes a request, a navigation type string ("
form-submission
" +- +
A pre-navigation check, which takes a request, a navigation type string ("
-form-submission
" or "other
"), and a policy as arguments, and - is executed during §4.2.5 Should navigation request of type from source in target be blocked + is executed during § 4.2.5 Should navigation request of type be blocked by Content Security Policy?. It returns "Allowed
" unless otherwise specified.- -
A navigation response check, which takes a request, a navigation type string ("
form-submission
" or "other
"), +- +
A navigation response check, which takes a request, a navigation type string ("
form-submission
" or "other
"), a response, a browsing context, a check type string ("source
" - or "response
"), and a policy as arguments, and is executed during §4.2.6 Should navigation response to navigation request of type from source + or "response
"), and a policy as arguments, and is executed during § 4.2.6 Should navigation response to navigation request of type in target be blocked by Content Security Policy?. It returns "Allowed
" unless otherwise specified.2.3.1. Source Lists
-Many directives' values consist of source lists: sets of strings which identify content that can be fetched and potentially embedded or - executed. Each string represents one of the following types of source +
Many directives' values consist of source lists: sets of strings which identify content that can be fetched and potentially embedded or + executed. Each string represents one of the following types of source expression:
-
-- +
Keywords such as
-'none'
and'self'
(which match nothing and the current URL’s origin, respectively)- +
Serialized URLs such as
-https://example.com/path/to/file.js
(which matches a specific file) orhttps://example.com/
(which matches everything on that origin)- +
Schemes such as
-https:
(which matches any resource having the specified scheme)- +
Hosts such as
-example.com
(which matches any resource on the host, regardless of scheme) or*.example.com
(which matches any resource on the host’s subdomains (and any of its subdomains' subdomains, and so on))- +
Nonces such as
-'nonce-ch4hvvbHDpv7xCSvXCs3BrNggHdTzxUA'
(which can match specific elements on a page)- +
Digests such as
'sha256-abcd...'
(which can match specific elements on a page)A serialized source list is an ASCII string, consisting of a +
A serialized source list is an ASCII string, consisting of a whitespace-delimited series of source expressions, adhering to the following ABNF grammar [RFC5234]:
-serialized-source-list = ( source-expression *( required-ascii-whitespace source-expression ) ) / "'none'" -source-expression = scheme-source / host-source / keyword-source +serialized-source-list = ( source-expression *( required-ascii-whitespace source-expression ) ) / "'none'" +source-expression = scheme-source / host-source / keyword-source / nonce-source / hash-source ; Schemes: "https:" / "custom-scheme:" / "another.custom-scheme:" -scheme-source = scheme-part ":" +scheme-source = scheme-part ":" ; Hosts: "example.com" / "*.example.com" / "https://*.example.com:12/path/to/file.js" -host-source = [ scheme-part "://" ] host-part [ ":" port-part ] [ path-part ] -scheme-part = scheme +host-source = [ scheme-part "://" ] host-part [ ":" port-part ] [ path-part ] +scheme-part = scheme ; scheme is defined in section 3.1 of RFC 3986. -host-part = "*" / [ "*." ] 1*host-char *( "." 1*host-char ) -host-char = ALPHA / DIGIT / "-" -port-part = 1*DIGIT / "*" -path-part = path-absolute (but not including ";" or ",") +host-part = "*" / [ "*." ] 1*host-char *( "." 1*host-char ) +host-char = ALPHA / DIGIT / "-" +port-part = 1*DIGIT / "*" +path-part = path-absolute (but not including ";" or ",") ; path-absolute is defined in section 3.3 of RFC 3986. ; Keywords: -keyword-source = "'self'" / "'unsafe-inline'" / "'unsafe-eval'" - / "'strict-dynamic'" / "'unsafe-hashes'" / - / "'report-sample'" / "'unsafe-allow-redirects'" +keyword-source = "'self'" / "'unsafe-inline'" / "'unsafe-eval'" + / "'strict-dynamic'" / "'unsafe-hashes'" / + / "'report-sample'" / "'unsafe-allow-redirects'" ISSUE: Bikeshedunsafe-allow-redirects
. ; Nonces: 'nonce-[nonce goes here]' -nonce-source = "'nonce-" base64-value "'" -base64-value = 1*( ALPHA / DIGIT / "+" / "/" / "-" / "_" )*2( "=" ) +nonce-source = "'nonce-" base64-value "'" +base64-value = 1*( ALPHA / DIGIT / "+" / "/" / "-" / "_" )*2( "=" ) ; Digests: 'sha256-[digest goes here]' -hash-source = "'" hash-algorithm "-" base64-value "'" -hash-algorithm = "sha256" / "sha384" / "sha512" +hash-source = "'" hash-algorithm "-" base64-value "'" +hash-algorithm = "sha256" / "sha384" / "sha512"The host-char production intentionally contains only ASCII characters; internationalized domain names cannot be entered directly as part of a serialized CSP, but instead MUST be Punycode-encoded [RFC3492]. For example, the domain
üüüüüü.de
MUST be represented asxn--tdaaaaaa.de
.Note: Though IP address do match the grammar above, only
127.0.0.1
will actually match a URL when used in a source - expression (see §6.6.2.5 Does url match source list in origin with redirect count? for details). The security + expression (see § 6.6.2.5 Does url match source list in origin with redirect count? for details). The security properties of IP addresses are suspect, and authors ought to prefer hostnames whenever possible.Note: The base64-value grammar allows both base64 and base64url encoding. These encodings are treated as equivalant when @@ -2204,31 +2665,31 @@
nonce-source
2.4. Violations
-A violation represents an action or resource which goes against the +
A violation represents an action or resource which goes against the set of policy objects associated with a global object.
-Each violation has a global object, which +
Each violation has a global object, which is the global object whose policy has been violated.
-Each violation has a url which is its global object’s
-URL
.Each violation has a status which is a +
Each violation has a url which is its global object’s
+URL
.Each violation has a status which is a non-negative integer representing the HTTP status code of the resource for which the global object was instantiated.
-Each violation has a resource, which is +
Each violation has a resource, which is either
-null
, "inline
", "eval
", or aURL
. It represents the resource which violated the policy.Each violation has a referrer, which is either
null
, or aURL
. It represents the referrer of the resource whose policy +Each violation has a referrer, which is either
-null
, or aURL
. It represents the referrer of the resource whose policy was violated.Each violation has a policy, which is the policy that has been violated.
-Each violation has a disposition, which is the disposition of the policy that has been violated.
-Each violation has an effective directive which is a non-empty string representing the directive whose +
Each violation has a policy, which is the policy that has been violated.
+Each violation has a disposition, which is the disposition of the policy that has been violated.
+Each violation has an effective directive which is a non-empty string representing the directive whose enforcement caused the violation.
-Each violation has a source file, which is +
Each violation has a source file, which is either
-null
or aURL
.Each violation has a line number, which is +
Each violation has a line number, which is a non-negative integer.
-Each violation has a column number, which +
Each violation has a column number, which is a non-negative integer.
-Each violation has a element, which is either
-null
or an element.Each violation has a sample, +
Each violation has a element, which is either
+null
or an element.Each violation has a sample, which is a string. It is the empty string unless otherwise specified.
Note: A violation’s sample will be populated with the first 40 characters of an inline script, event handler, or style that caused an violation. Violations @@ -2236,27 +2697,27 @@
2.4.1. Create a violation object for global, policy, and directive
Given a global object (global), a policy (policy), and a string (directive), the following algorithm creates a new violation object, and populates it with an initial set of data:
Let violation be a new violation whose global
object is global, policy is policy, effective directive is directive, and resource is null
.
If the user agent is currently executing script, and can extract a source file’s URL, line number, and column number from the global, set violation’s source file, line number, and column number accordingly.
-Is this kind of thing specified anywhere? I didn’t see anything +
Is this kind of thing specified anywhere? I didn’t see anything that looked useful in [ECMA262].
Note: User agents need to ensure that the source file is the URL requested by the page, pre-redirects. If that’s not possible, user agents need to strip the URL down to an origin to avoid unintentional leakage.
-If global is a Window
object, set violation’s referrer to global’s document
's referrer
.
Set violation’s status to the HTTP status code for the resource associated with violation’s global object.
-How, exactly, do we get the status code? We don’t actually store it +
How, exactly, do we get the status code? We don’t actually store it anywhere.
-Return violation.
Let directive be the result of executing §6.7.1 Get the effective directive for request on request.
-Let violation be the result of executing §2.4.1 Create a violation object for global, policy, and directive on request’s client’s global object, policy, and directive.
-Let directive be the result of executing § 6.7.1 Get the effective directive for request on request.
+Let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on request’s client’s global object, policy, and directive.
+Set violation’s resource to request’s url.
Note: We use request’s url, and not its current url, as the latter might contain information about redirect targets to which the page MUST NOT be given access.
-Return violation.
A server MAY declare a policy for a particular resource - representation via an HTTP response header field whose value is a serialized CSP. This mechanism is defined in detail in §3.1 The Content-Security-Policy HTTP Response Header Field and §3.2 The Content-Security-Policy-Report-Only HTTP Response Header Field, and the integration with Fetch - and HTML is described in §4.1 Integration with Fetch and §4.2 Integration with HTML.
-A policy may also be declared inline in an HTML document via a meta
element’s http-equiv
attribute, as described in §3.3 The <meta> element.
A policy may also be declared inline in an HTML document via a meta
element’s http-equiv
attribute, as described in § 3.3 The <meta> element.
Content-Security-Policy
HTTP Response Header Field The Content-Security-Policy
HTTP response header field is the preferred mechanism for delivering a policy from a server to a
+
The Content-Security-Policy
HTTP response header field is the preferred mechanism for delivering a policy from a server to a
client. The header’s value is represented by the following ABNF [RFC5234]:
Content-Security-Policy = 1#serialized-policy ; The '#' rule is the one defined in section 7 of RFC 7230 ; but it incorporates the modifications specified ; in section 2.1 of this document.-
Content-Security-Policy: script-src 'self'; report-to csp-reporting-endpoint@@ -2302,9 +2763,9 @@
When the user agent receives a Content-Security-Policy
header field, it
- MUST parse and enforce each serialized CSP it contains as described in §4.1 Integration with Fetch, §4.2 Integration with HTML.
Content-Security-Policy-Report-Only
HTTP Response Header Field The Content-Security-Policy-Report-Only
HTTP response header field allows web developers to experiment with policies by monitoring (but
+
The Content-Security-Policy-Report-Only
HTTP response header field allows web developers to experiment with policies by monitoring (but
not enforcing) their effects. The header’s value is represented by the following ABNF [RFC5234]:
Content-Security-Policy-Report-Only = 1#serialized-policy ; The '#' rule is the one defined in section 7 of RFC 7230 @@ -2315,8 +2776,8 @@