Note somewhere that redirects are covered by fetch directives.

[mikewest]

@ptoomey3 would like some more clarity in the spec around the redirect behavior of the various directives that affect redirects: https://twitter.com/patricktoomey/status/721036954146476032 So let's be explicit about that somewhere.

[mikewest]

The text in https://w3c.github.io/webappsec-csp/#fetch-integration now seems pretty clear. @ptoomey3: Would you appreciate any more adjustment?

[ptoomey3]

It is quite possible that folks more intimately familiar with the fetch spec would find the current behavior/description within the CSP spec obvious. But, as a standalone section, I still find it a bit unclear how redirects would/should interact with CSP.

§4.1.3 Should request be blocked by Content Security Policy? is called as part of step #5 of its Main Fetch algorithm. This allows directives' pre-request checks to be executed against each request before it hits the network, and against each redirect that a request might go through on its way to reaching a resource.

So, step 5 says to:

If should fetching request be blocked due to a bad port, should fetching request be blocked as mixed content, or should fetching request be blocked by Content Security Policy returns blocked, set response to a network error. [MIX] [CSP]

This defers the question back to the CSP spec with the following:

1. Let CSP list be request’s client’s global object’s CSP list.
   ...
   Return result.

So, if this logic is "executed against each request before it hits the network, and against each redirect that a request might go through" then one needs to understand what represents "a request’s client’s global object’s CSP list". Inside section 4.1 this is discussed a bit:

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.

This description then has a note below it:

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.

All together, it reads to me like one might expect that, given a redirect in a "response", the browser would parse the CSP in that response before acting on the response (in a similar way to how "before we handle the Set-Cookie header").

Again, maybe I'm reading it this way because I don't have intimate familiarity with the fetch spec. And, those that do (i.e. browser makers/people that need to implement CSP) would read all of the above and not reach the same conclusions/expectations. But, I think if CSPs perspective is that all CSP headers found in redirect responses are ignored, it might be stated more simply as:

A fetch request abides by the CSP list found in the global object as it exited when the initial fetch request was made. Any CSP headers found in redirect responses are ignored.

Setting aside whether the current spec's description is clear or not, the bit about Set-Cookie further reinforced what I find so confusing about the current behavior with redirects. Let's say I make a request to /foo and the response to /foo is a 302 redirect to /bar. And, contained within the redirect response to /foo is a Set-Cookie header. The request to /bar will be made with the most recent cookie value. In the same, way, I was expecting that to apply to CSP. If my response contains a new form-action source and the redirect it targeting that source, I expected it to be allowed.

As an aside, the issue with 302 redirects and form-action has become so prevalent internally that we now have a helper method people can call to perform a meta-redirect when they need to redirect off-site. This feels like a bit of a CSP smell.