Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify CSP header recommendations for non-HTML pages #520

Open
kravietz opened this issue Oct 12, 2016 · 8 comments
Open

Clarify CSP header recommendations for non-HTML pages #520

kravietz opened this issue Oct 12, 2016 · 8 comments

Comments

@kravietz
Copy link

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
Copy link
Member

annevk commented Oct 12, 2016

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
Copy link

Malvoz commented Apr 30, 2019

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
Copy link
Member

annevk commented May 1, 2019

How is it redundant for text/xml and friends?

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

@briansmith
Copy link

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
Copy link

Malvoz commented Nov 16, 2019

Related issue w3c/webappsec-csp#336.

@Malvoz
Copy link

Malvoz commented Dec 7, 2019

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.

aomarks added a commit to lit/lit.dev that referenced this issue Sep 30, 2021
- For all requests other than our HTML entrypoints and the playground worker script, serve a super strict policy,  just in case a response that shouldn't normally allow any code execution somehow actually does. Based on [this](w3c/webappsec#520 (comment)) and [this](webhintio/hint#3403 (comment)) comment.

- Add some directives that I found through https://csp-evaluator.withgoogle.com/ and [this comment](w3c/webappsec#520 (comment)).

- Temporary fix for inline Google Analytics script which was being reported as a violation. See #531 for details. Will fix properly in followup.
@SmashManiac
Copy link

Edge's developer tools currently flags CSP headers on most non-HTML files as a performance issue, referencing the same webhint no-html-only-headers rule mentioned in #520 (comment). I'm not sure if this is a good recommendation due to the reasons @briansmith previously listed. It may be worth revisiting this issue sooner rather than later to prevent the spread of misinformation one way or the other.

@amalkrishnan43216
Copy link

amalkrishnan43216 commented Aug 19, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants