CSP3: The effect of multiple policies

[april]

This affects CSP2 as well, but I don't think it's likely to get updated there.

The example used is this:

Content-Security-Policy: default-src 'self' http://example.com http://example.net;
                         connect-src 'none';
Content-Security-Policy: connect-src http://example.com/;
                         script-src http://example.com/

In reality, it seems pretty much every user agent I've seen just joins multiple copies of the same header (except Set-Cookie) together with , or ,. This is in violation of RFC 7230, but they all do it anyways -- something I only found because it broke a lot of my HTTP Observatory scans. It doesn't help that the RFC 7230 isn't particularly clear on what clients should do if they can't be joined.

When looking at Chrome with req.getAllResponseHeaders() with the CSP header, CSP headers are joined with ,. Not sure if they're processed that way, but overall there's just a ton of weird things that happen in pretty much all HTTP clients when they receive the same header multiple times. So for this case, it gets processed like this:

Content-Security-Policy: default-src 'self' http://example.com http://example.net; connect-src 'none';, connect-src http://example.com/; script-src http://example.com/

So I think it would get treated as , and connect-src, but possibly ,connect-src in other clients. Given the ambiguity, this whole long ramble-y post is my way of saying that the example should probably not use multiple Content-Security-Policy: headers, and instead use a header and a meta tag.

It's far more likely to occur anyways: in my scan of the Top 1M sites, multiple CSP headers only occurs once. This compares to about 3400 times for multiple X-Frame-Option headers.

[mikewest]

I think this spec doesn't need to be responsible for defining UA behavior around headers, but I do think it should be clear about the situation in which two headers are present.

Chrome deals with this by splitting on , before processing any header (also inside <meta>): https://blink.lc/chromium/tree/third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicy.cpp#n258. That is, Content-Security-Policy: default-src 'self', connect-src 'self' defines two distinct policies, and is indistinguishable from Content-Security-Policy: default-src 'self' + Content-Security-Policy: connect-src 'self'. That's the behavior I'd like this document to require, and I think it's fairly well in line with RFC7230's "A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma." in https://tools.ietf.org/html/rfc7230#section-3.2.2.

I think the CSP3 spec mandates this behavior today by defining the header's grammar as 1#serialized-policy, and then stating that each serialized policy contained in the header field must be parsed and {enforced,monitored}". The example was meant to solidify that ~implicit understanding. What would you suggest adding to the document to further clarify?

[mikewest]

(Also, please keep filing bugs! But please file them against https://github.com/w3c/webappsec-csp/issues rather than the generic webappsec repo. :) )

[april]

Oops, sorry! There were a bunch of CSP bugs in this repo, so I didn't realize there was a separate place I should file.

Anyways, regardless of UA behavior, I just feel like the example given should be the most likely scenario — that is, that of a CSP header and a CSP meta tag — and not multiple HTTP headers, something that the HTTP specification says that senders MUST NOT do, despite frequently doing it anyways.