0

From the OWASP's website https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html:

Send a Content-Security-Policy HTTP response header from your web server.

Content-Security-Policy: ...

Using a header is the preferred way and supports the full CSP feature set. Send it in all HTTP responses, not just the index page.

I don't understand how that could be true as it is possible to set the Content-Security-Policy by using a meta tag in the HTML. I also don't see how the policy can apply to anything else but HTML pages.

Does anyone have idea why that statement above was made and if it is safe to only send HTTP header Content-Security-Policy for text/html responses?

By the way, the policy is too big and I would like to sent as fewer bytes as possible.

Nikolay Dimitrov
  • 1,766
  • 1
  • 14
  • 23

2 Answers2

2

This is still something that’s not formally specified and there ai still some debate on this: https://github.com/w3c/webappsec/issues/520

In general there’s two arguments here:

On the one hand some other file types (XML, PDF, perhaps even SVGs) could benefit from CSP and any resource could become the page by right clicking and opening in a separate tab.

On the other hand CSPs can get quite big and are usually written for HTML pages. So a bit wasteful to send on other resources and most of it won’t be relevant.

The right answer (as suggested by above) is probably to have a reduced, and very strict, CSP for all non-HTML responses.

But I think for most people having it on the HTML only will be good enough and bring most of the benefits of CSP. Then again CSP is an advanced technique so if going as far as that, then why not do it properly?

Barry Pollard
  • 40,655
  • 7
  • 76
  • 92
  • That's a great answer, I didn't think about PDFs and SVGs, makes sense. As you suggested, I will probably go for very short and strict CSP for all other content types besides `text/html` – Nikolay Dimitrov Oct 29 '21 at 01:05
2

Using a header is the preferred way and supports the full CSP feature set.

I don't understand how that could be true as it is possible to set the Content-Security-Policy by using a meta tag in the HTML.

  1. Inside the meta tag are not supported the directives:
  • report-to and report-uri
  • frame-ansectors
  • sandox

  1. Also meta tag does not support Content-Security-Policy-Report-Only feature, only the Content-Security-Policy.

  2. All resources that start loading before meta tag in the HTML code are not affected by CSP. Malicious scripts can be injected as first item of the <head> section just before meta tags

  3. The nonce-value is exposed in meta tag therefore can be easely stealing by script and reuse.

  4. Using meta tag you can only set the CSP for HTML pages, but CSP is applied for XSLT in the XML pages, and for some other kinds of content (see below).

Therefore indeed an HTTP header is the preferred way to delivery CSP and using CSP via meta tag does not allow you to use full CSP feature set.

Send it in all HTTP responses, not just the index page.

I also don't see how the policy can apply to anything else but HTML pages.

The specification had in mind a little different - you should send CSP with any response page with HTML content, not only for 200 OK, but even for 404 Not found 403 Access Forbidden, etc.
Because these pages has access to cookie that can be steal in the page not covered by CSP.

CSP is applied not only to HTML pages, but to XSLT in XML-pages, to external javascripts files for workers (in Firefox). Also frame-ancestors directive of CSP HTTP header applies to any content (JPEG/GIF/PNG/PDF/MP4/etc) intended to be embedded into iframe, see the nitty-gritty here.

granty
  • 7,234
  • 1
  • 14
  • 21