问题
I'm currently adding the Content Security Policy (CSP) header to our application. I'm wondering onto which files the header must be attached to. After some research, I did not find a clear answer to it.
Twitter, e.g. only added it to the actual HTML document. Facebook, however, added it to almost every resource and the HTML document (HTML, JS, CSS, etc.).
So, is it necessary to add the Content Security Policy header to each served resource file or only to the HTML document? How does it work with Ajax (JSON content) requests? How does it work with SPAs (only the index.html file or all resources)? I don't want to slow down the page by adding long CSP headers to each file if it is not necessary from a security point of view.
EDIT:
To clarify: Do browser treat images or other non-document resources differently when they come with a CSP header attached?
回答1:
CSP is not intended as a first line of defense against content injection vulnerabilities.
...
New Answer II
Question:
To clarify: Do browser treat images or other non-document resources differently when they come with a CSP header attached?
My Answer:
First, define 'non-document'? W3 (the guys who set how the internet actually works) have a definition of "document" and I will assume your definition is the same.
If it is not, please clarify accordingly.
The W3 Rules on Content Security Policy (as of October 2018) state that the goals of CSP is to:
Mitigate the risk of content-injection attacks by giving developers fairly granular control over:
The resources which can be requested (and subsequently embedded or executed) on behalf of a specific Document or Worker
The execution of inline script
Dynamic code execution (via eval() and similar constructs)
The application of inline style
Mitigate the risk of attacks which require a resource to be embedded in a malicious context (the "Pixel Perfect" attack described in [TIMING], for example) by giving developers granular control over the origins which can embed a given resource.
Provide a policy framework which allows developers to reduce the privilege of their applications.
Provide a reporting mechanism which allows developers to detect flaws being exploited in the wild.
Note point 1(i);
"The resources which can be requested (and subsequently embedded or executed) on behalf of a specific Document or Worker"
The document is defined as above and a work is defined -essentially- as something that uses a Javascript DOM model (this may be incorrect).
So the CSP is expected to apply to the documents (a given) and workers.
Are other (MP3, PDF, etc.) files documents or workers? They are not documents, but the way they are handled in browsers does imply they are contained in a document structure.
Please see this old Chrome Bug report. Whereby a PDF failed to load contents due to the websites CSP settings and the PDF was actually being loaded by a browser plugin (native to all modern browsers) and therefore was affected by the object-src CSP.
This is CSP version 1, and I have no reason to think that either the way browsers handle non-document files or the way CSP integrates have changed significantly since that bug was filed.
Therefore: browsers are not REQUIRED to apply CSP to non-document and non-worker objects, but due to the way browsers operate they probably will apply CSP headers to non-document and non-worker objects, by fact that these objects will be wrapped in document models for ease of the browser handling files within itself.
But This is at the coding disgression of the browser and should not be expected as of October 2018.
回答2:
Browsers that support the HTTP Content Security Policy response header will prevent images (and other content) from loading for any page where the response header or a meta tag contains Content Security Policy directives that limit the domains considered as valid content sources, require all content to be loaded via HTTPS, etc. Most widely used modern browsers support Content Security Policy and apply it to control the majority of content resources (including images) associated with any HTTP request (except that web worker resource control is not supported in Safari and IE and may not be supported in Edge or Opera).
You can specifically include img-src policy directives in your Content Security Policy to restrict the domains considered as valid sources for images as well as require the HTTPS scheme, etc. There are also specific directives available for a variety of other resources including fonts, frames, media (audio, video, etc), scripts, stylesheets, web workers, etc.
You will either need to include your Content Security Policy as part of the HTTP response header that is returned from your web server as part of each HTTP request where you wish to limit valid content sources or ensure that the requested page includes a Content Security Policy meta tag like...
<meta http-equiv="Content-Security-Policy" content="default-src 'self';">
Note that IE 10+ browsers support Content Security Policy response headers but not meta tags (also there are some specific implementation details you need to attend to if you want to support IE).
回答3:
slow down the page by adding long CSP headers to each file
Supposedly, with 304 Not Modified status - CSP headers are not being sent
- only on initial loading
来源：https://stackoverflow.com/questions/54203764/content-security-policy-csp-header-onto-each-file-or-only-the-actual-html-pag