I've built a web application (with my favourite language Fantom!) and am in the process of locking it down from XSS and other such attacks by supplying industry standard HTTP response headers.
My question is, for which responses should the headers be set?
I could set the headers for every response, but that seems pretty wasteful given most requests will be for images, fonts, stylesheets, etc.. The Content-Security-Policy header in particular can get quite lengthy.
As a lot of the headers relate to the owning HTML page (and the Javascript contained within), I get the feeling most of them need only be set for HTML pages.
I've looked at various resources such as:
And while they explain what the headers do, they don't explain for which resources they should be used and served for!
I've made a list below of HTTP response headers and for which Content-Types I think they should be served with. But does anyone know if this is correct?
HTTP Response Header text/html All Content-Types
------------------------- --------- -----------------
Content-Security-Policy X
Referrer-Policy X
Strict-Transport-Security X
X-Content-Type-Options X
X-Frame-Options X
X-XSS-Protection X
(When I say text/html I also include application/xhtml+xml.)
Referrer-Policy is under all content types due to CSS being able to load fonts and images.
Theoretically, only 'active' documents should need it much like the X-XSS-Protection header (related answer here from Info Security). As long as the policy is set on the main document (even through a Meta tag), external resources should be blocked based on that policy, not the policy on the external resource (easy to see when loading CDN files which almost certainly do not have your CSP, or any CSP, set).
So I would say your estimate is correct; text/HTML and XML absolutely should have it, anything that can execute Javascript. It shouldn't matter for static resources. They'll be blocked or allowed based on the main Document's CSP.
I will admit that personally I simply send them on all resources served directly from my server as I'd rather be paranoid than screw something up and the few dozen bytes per request don't appear to be a big impact especially on a site that doesn't serve a great deal of requests. And if your site does serve an extreme amount of requests...usually best to cut down on requests before trying to shrink your headers.
As with anything like this I'd be sure to test your specific implementation and try loading some resources the CSP should block. You never know when a browser implementation may be flawed (or more frequently, a typo or over/under eager application of your own rules).