diff --git a/index.bs b/index.bs index 19587874ad..b5c4f34b6d 100644 --- a/index.bs +++ b/index.bs @@ -586,29 +586,25 @@ spec: INFRA; urlPrefix: https://infra.spec.whatwg.org/ and is executed during [[#should-block-response]]. This algorithm returns "`Allowed`" unless otherwise specified. - 3. A response check, which takes a - request, a response, and a policy as arguments, - and is executed during [[#should-block-response]]. This algorithm returns - "`Allowed`" unless otherwise specified. - - 4. An inline check, which takes an {{Element}}, a + 3. An inline check, which takes an {{Element}}, a type string, a policy, and a source string as arguments, and is executed during [[#should-block-inline]] and during [[#should-block-navigation-request]] for `javascript:` requests. This algorithm returns "`Allowed`" unless otherwise specified. - 5. An initialization, which takes a {{Document}} + 4. An initialization, which takes a {{Document}} or global object and a policy as arguments. This - algorithm is executed during [[#run-document-csp-initialization]], and has no - effect unless otherwise specified. + algorithm is executed during [[#run-document-csp-initialization]] and + [[#run-global-object-csp-initialization]]. Unless otherwise specified, it has no + effect and it returns "`Allowed`". - 6. A pre-navigation check, which takes a + 5. 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 [[#should-block-navigation-request]]. It returns "`Allowed`" unless otherwise specified. - 7. A navigation response check, which takes a + 6. 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 @@ -989,48 +985,8 @@ spec: INFRA; urlPrefix: https://infra.spec.whatwg.org/ 2. [[#should-block-response]] is called as part of step 11 of the Main Fetch algorithm. This allows directives' post-request checks - and response checks to be executed on the response delivered - from the network or from a Service Worker. - - A policy is generally enforced upon a global object, but the - user agent needs to parse any policy - delivered via an HTTP response header field before any global object - is created in order to handle directives that require knowledge of a - response's details. To that end: - - 1. A response has an associated CSP list which - contains any policy objects delivered in the response's - header list. - - 2. [[#set-response-csp-list]] is called in the HTTP fetch and - HTTP-network fetch algorithms. - - Note: These two calls should ensure that a response's - CSP list is set, regardless of how the - response is created. If we hit the network (via HTTP-network - fetch, then we parse the policy before we handle the `Set-Cookie` - header. If we get a response from a Service Worker (via HTTP fetch, - we'll process its CSP list before handing the - response back to our caller. - - Note: A fetch request abides by the global object's - CSP list including any redirects it might follow. - Any Content-Security-Policy headers found in a redirect - response are ignored. - -

- Set |response|'s CSP list -

- - Given a response (|response|), this algorithm evaluates its - header list for serialized CSP values, and - populates its CSP list accordingly: - -
    - 1. Set |response|'s [=response/CSP list=] to the result of parsing |response|'s - Content Security Policies. -
+ to be executed on the response delivered from the network + or from a Service Worker.

Report Content Security Policy violations for |request| @@ -1118,24 +1074,7 @@ spec: INFRA; urlPrefix: https://infra.spec.whatwg.org/ response. That is, that a Service Worker hasn't substituted a file which would violate the page's CSP. - 4. For each |policy| in |response|'s CSP list: - - 1. For each |directive| in |policy|: - - 1. If the result of executing |directive|'s - response check on |request|, |response|, - and |policy| is "`Blocked`", then: - - 1. Execute [[#report-violation]] on the result of executing - [[#create-violation-for-request]] on |request|, and |policy|. - - 2. If |policy|'s disposition is "`enforce`", - then set |result| to "`Blocked`". - - Note: This portion of the check allows policies delivered with the - response to determine whether the response is allowed to be delivered. - - 5. Return |result|. + 4. Return |result|.

@@ -1187,6 +1126,9 @@ spec: INFRA; urlPrefix: https://infra.spec.whatwg.org/ apply directive's navigation checks, as well as inline checks for navigations to `javascript:` URLs. + 11. [[#run-global-object-csp-initialization]] is called during the run a worker + algorithm. +

Run `CSP` initialization for a `Document`

@@ -1200,7 +1142,8 @@ spec: INFRA; urlPrefix: https://infra.spec.whatwg.org/ 1. For each |directive| in |policy|: 1. Execute |directive|'s initialization - algorithm on |document|. + algorithm on |document|, and assert: its returned value is + "`Allowed`".

Retrieve the CSP list of an |object| @@ -1407,6 +1350,28 @@ spec: INFRA; urlPrefix: https://infra.spec.whatwg.org/ 4. Return |result|. +

+ Run `CSP` initialization for a global object. +

+ + Given a global object (|global|), the user agent performs the + following steps in order to initialize CSP for |global|. This algorithm + returns "`Allowed`" if |global| is allowed, and "`Blocked`" otherwise: + +
    + 1. Let |result| be "`Allowed`". + + 2. For each |policy| in |global|'s [=global object/CSP list=]: + + 1. For each |directive| in |policy|: + + 1. Execute |directive|'s initialization algorithm on + |global|. If its returned value is "`Blocked`", then set |result| to + "`Blocked`". + + 3. Return |result|. +
+

Integration with ECMAScript

ECMAScript defines a {{HostEnsureCanCompileStrings()}} abstract operation @@ -3319,56 +3284,40 @@ spec: INFRA; urlPrefix: https://infra.spec.whatwg.org/ delivered in a `Content-Security-Policy-Report-Only` header, or within a <{meta}> element. -
- `sandbox` Response Check -
- - This directive's response check algorithm is as - follows: - - Given a request (|request|), a response (|response|), and a - policy (|policy|): - - 1. Assert: |response| is unused. - - 2. If |policy|'s disposition is not "`enforce`", then - return "`Allowed`". - - 3. If |request|'s destination is one of - "`serviceworker`", "`sharedworker`", or "`worker`": - - 1. If the result of the Parse a sandboxing directive algorithm - using this directive's value as the input - contains either the sandboxed scripts browsing context flag or - the sandboxed origin browsing context flag flags, return - "`Blocked`". - - Note: This will need to change if we allow Workers to be sandboxed into - unique origins, which seems like a pretty reasonable thing to do. - - 4. Return "`Allowed`". -
`sandbox` Initialization
This directive's initialization algorithm is responsible for adjusting a {{Document}}'s forced sandboxing flag set - according to the `sandbox` values present in its policies, as - follows: + and for checking whether a worker is allowed to run according to the `sandbox` + values present in its policies as follows: Given a {{Document}} or global object (|context|) and a policy (|policy|): 1. If |policy|'s disposition is not "`enforce`", or - |context| is not a {{Document}}, then abort this algorithm. + |context| is a {{WorkletGlobalScope}}, then abort this algorithm. + + 2. Let |sandboxing flag set| be a new [=/sandboxing flag set=]. + + 3. Parse a sandboxing directive using this directive's value as the input, and |sandboxing flag set| as the output. + + 4. If |context| is a {{WorkerGlobalScope}}: + + 1. If |sandboxing flag set| contains either the sandboxed scripts browsing + context flag or the sandboxed origin browsing context flag flags, + return "`Blocked`". + + Note: This will need to change if we allow Workers to be sandboxed into unique + origins, which seems like a pretty reasonable thing to do. + + 5. If |context| is a {{Document}}: - Note: This will need to change if we allow Workers to be sandboxed, - which seems like a pretty reasonable thing to do. + 1. Set |context|'s forced sandboxing flag set to |sandboxing flag set|. - 2. Parse a sandboxing directive using this directive's - value as the input, and |context|'s forced - sandboxing flag set as the output. + 6. Return "`Allowed`".

Navigation Directives @@ -3667,9 +3616,9 @@ spec: INFRA; urlPrefix: https://infra.spec.whatwg.org/ that document. New directives SHOULD use the pre-request check, - post-request check, response - check, and initialization hooks in order to - integrate themselves into Fetch and HTML. + post-request check, and + initialization hooks in order to integrate themselves + into Fetch and HTML.

Matching Algorithms