Is it safe to send Content-Security-Policy for dynamically generated pages with text/html and other hypertext content-types only or do I need to send this header for all files including static assets - images, JS and CSS files?

  • 1
    Is there a reason to do so? A reason against it would for example be text/xml content which can be rendered as (x)HTML, but I do not see the point in configuring the server to send different security headers based on mimetype.
    – allo
    Commented May 25, 2018 at 14:37
  • @allo the reason is that CSP headers can be generated by the web application so there is no need to update server configuration when developers need to update CSP.
    – AlexD
    Commented May 25, 2018 at 14:58
  • That's a good reason. Do you make sure there are no files which may contain dynamic content outside of the files generated by the web application? a png should be quite safe, but I would be not that sure for svg for instance or folders for user uploads and similar.
    – allo
    Commented May 25, 2018 at 15:04
  • @allo I have checked CSP standard and it mention that CSP applies to svg but I'm not sure about other types.
    – AlexD
    Commented May 25, 2018 at 15:13
  • 1
    Please see the answer referenced on StackOverFlow.com: stackoverflow.com/a/38167905/367988
    – Basil A
    Commented Mar 14, 2019 at 8:25

2 Answers 2


There are, cases where users can influence MIME type based on different factors. For example, IE can be fooled to render text/plain as text/html within certain circumstances. And, again there are various other MIME types which are rendered and can exfiltrate data. For example, even pdf files can execute JavaScript and so can Flash, SVG, XML or any other plug-in handled content types.

Therefore, it's best to apply CSP using configuration file on all rendered contents.

On a side note, always return correct content type with correct charset attribute along with X-Content-Type-Options: nosniff header.

  • I have nosniff already applied. For user uploaded files I can apply a strict CSP policy which doesn't need to change. But the files I have in mind are static assets of the web application which are managed by developers.
    – AlexD
    Commented May 25, 2018 at 17:34
  • Also, I understand that CSP can limit plugins used on the page but is the CSP honored by browser plugins?
    – AlexD
    Commented May 25, 2018 at 17:54
  • No, plug-ins can do whatever they want. And, please remember, on same origin, any MIME type can be sniffed unless instructed not to. Commented May 26, 2018 at 4:44
  • So, what is the point of applying CSP for a PDF if it is ignored by a plugin used to render it?
    – AlexD
    Commented May 26, 2018 at 16:24
  • Well, PDFs no longer require a separate plug-in. It is handled by the pdf.js library. Commented May 26, 2018 at 18:52

In addition to text/html responses, web worker responses (text/javascript) should also have a Content-Security-Policy header:

WebWorkers | Content security policy

Workers are considered to have their own execution context, distinct from the document that created them. For this reason they are, in general, not governed by the content security policy of the document (or parent worker) that created them.

There are some other excellent answers on this topic here. In short, CSP governs what can be done inside a document, and web pages are the normal document, though it's conceivable a browser could support other types of documents (SVG? PDF?). CSP is applied at the root of the execution context, so it doesn't make sense on accessory requests.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .