When is content security policy (CSP) not appropriate?



  • We've recently conducted a security review of our identity server website and one of the finding was about missing CSP header. We do have implementation of request filter to add CSP on a controller level. So my question is, is there any documentation out there recommending CSP for or against certain response? It seems overkill to include CSP in all responses.

    Here is what I could find which makes sense for pages that have reference to 3rd party code like analytics. https://developers.google.com/web/fundamentals/security/csp

    Even on a fully static website, which does not accept any user input, a CSP can be used to enforce the use of Subresource Integrity (SRI). This can help prevent malicious code from being loaded on the website if one of the third-party sites hosting JavaScript files (such as analytics scripts) is compromised.

    Here are some responses I am questioning whether they are appropriate. Finding some documentation around it would help us justify whether or not it is worth adding them.

    • Non HTML response (json, css, etc...)
    • Redirect response (redirect 302)


  • CSP is only in effect on content that creates its own rendering context. In general, this means two kinds of content: HTML and SVG (other XML-based types, such as RSS/ATOM, might also support CSP in the few browsers that still support them; I'm not sure). These might be full pages, frames, iframes, objects, or (in the case of SVG) images. Note that it only impacts content that is rendered directly into the page; if the contents of an iframe are retrieved using XHR/Fetch and then dynamically inserted into the iframe's document, then CSP headers on the XHR/Fetch response will not have any effect (CSP in HTML meta tags will still be effective when the iframe loads).

    Additionally, subcontexts inherit CSP from their parent context. This means that you don't need to set a CSP for something like an SVG or iframe if you set it for the parent page. However, it's still a good idea; if there's an XSS vuln in a subcontext (yes, SVG can contain script!), an attacker would just navigate the victim to the SVG/iframe/etc. URL directly, rather than to the parent page, and you don't want them to be able to skip CSP that way. It's also possible to extend or override the parent context CSP, which is useful in some cases (e.g. allowing inline styles in SVG but not elsewhere).

    Mind you, there's no harm - aside from slightly more network traffic - in sending CSP with every response. But if you want to reduce it, HTML and SVG are the areas to focus on. Redirects and error pages with no content are probably fine to skip, but if there's any HTML content, it can use SVG. If you want to go extremely minimal for some reason, CSP can be safely skipped on any page that neither handles any user-sourced data (including stored data from the DB) nor includes any externally-sourced content (scripts, stylesheets, images, iframes, etc.). However, it's best to send CSP with such responses anyhow, as the content of those pages might change in the future and it's best to be already protected (especially at such minimal cost).



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2