Clarify CSP header recommendations for non-HTML pages

[kravietz]

As some application security vendors started checking for the presence of the CSP header and raise lack of it as an issue, I think it's necessary to clarify when precisely for which resources it's really recommended to return CSP header. As it seems to me, the CSP is only meaningful for text/html documents since they are the original place where all the resources regulated by a CSP (CSS, images, script etc) are referred from.

The CSP header delivery is discussed in paragraph 3 of the CSP3 draft and the applicability to HTML documents is kind of implied by the alternative delivery via <meta> but never stated explicitly.

[annevk]

It's applicable to all workers and I think it has an effect on all resources with respect to cookies actually (although I don't recall the directive for that).

Furthermore, given that you can navigate to any resource and turn it into a document that way, it probably makes sense to just use it everywhere. Otherwise someone could navigate an <iframe> to an image and maybe bypass some stuff through that document. (Although arguably you've already lost at that point.)

[Malvoz]

There's little documentation on which resources we should respond with a CSP, while we could send it for everything - concerns are "how much “bloat” it will add" (header bloat).

Currently webhint.io warns against CSP for content other than text/html. Fixed in webhintio/hint#2618.

The "Workers & CSP" relation is documented here:
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers#Content_security_policy

@annevk not narrowing this down to CSP, do you think spec editors are willing specify to which MIME-type any respective HTTP header applies to?

[annevk]

How is it redundant for text/xml and friends?

Also, that ignores workers, which use a JavaScript MIME type (typically).

[briansmith]

I think that CSP for non-HTML resources is something that just hasn't been decided yet. According to https://pdfium.googlesource.com/pdfium/+/master/README.md, pdfium (Chrome's PDF viewer) may be built with JS support so IMO it would be good for it to honor CSP when rendering PDFs. (I myself have run into cases where the lack of JS support for PDFs has caused real inconvenience.)

More generally, I would say that browsers should pass the Content-Security-Policy response header field to any plugins (or similar) that will render non-HTML content in the page so that the plugin can enforce it within the content. (Whether browsers currently take this advice is different than whether they should eventually take it. Whether plugins currently do such enforcement is different than whether they should.) On the other hand, consider https://stackoverflow.com/questions/37795479/opening-a-pdf-embedded-in-iframe-in-chrome-with-content-security-policy-plugin; based on that, it seems some implementations may currently do something that's incompatible with what I'm suggesting here.

If you think that Content-Security-Policy is irrelevant for a particular document, and/or the server hasn't been configured to have a different CSP for a given response, then I would recommend sending Content-Security-Policy: base-uri 'none'; default-src 'none'. If you are using HTTP/2 then, after the first such response, this will be compressed to almost nothing for future responses.

If there is no Content-Type then browsers will do sniffing (sometimes). Thus you should generally assume the worst when there is no Content-Type header field. Thus Content-Security-Policy: base-uri 'none'; default-src 'none' is important when there is no Content-Type too, unless/until somebody writes down the specific rules for when omitting the CSP header field is safe.

[Malvoz]

Related issue w3c/webappsec-csp#336.

[Malvoz]

Per @briansmith's recommendation of base-uri 'none'; default-src 'none' for when Content-Type is missing, I'd expand that policy to at least:

base-uri 'none';
default-src 'none';
form-action 'none';
frame-ancestors 'none'

As default-src only cover fetch directives.