CODEWITHSUNDEEP
content-security-policywebsecurity
j3rbrown
j3rbrown

Reputation: 163

Should Content-Security-Policy header be applied to all resources?

Is it necessary to apply the Content-Security-Policy Header to all resources on your domain (images/CSS/JavaScript) or just web pages?

For example, I noticed that https://content-security-policy.com/images/csp-book-cover-sm.png has a CSP header.

I noticed that https://content-security-policy.com/images/csp-book-cover-sm.png has a CSP header.

Upvotes: 6

Views: 5585

Answers (2)

Halvor Sakshaug
Halvor Sakshaug

Reputation: 3475

Most of the directives of CSP are only relevant to web pages that are rendered in a browser, as CSP controls the allowed sources for content of such pages. You will typically only need to set it on non-redirect responses with content type as "text/html" but it could also apply to edge cases such as SVG files including script.

The frame-ancestors directive can however be relevant for all file types that can be displayed in the browser in an iframe, such as images, media, pdf, etc.

As it is often simpler or only possible to just add a response header to all responses, CSPs are often applied to all content types and codes even though they are not strictly needed. Additionally it is recommended to add a CSP with a strict frame-ancestors to REST APIs to prevent drag-and-drop style clickjacking attacks, see https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html#security-headers.

Upvotes: 5

Frédéric
Frédéric

Reputation: 9864

Yes, a Content Security Policy should be applied to all resources. At least a minimal CSP should still be applied to resources for which you think they do not need your full CSP. (If unsure, better apply your full CSP.)

By example, the CSP of a Web page does not apply to Web Workers. That is the one emitted on their script that is applied. If none, they will not have a CSP. See this MDN article about Web Workers.

To specify a content security policy for the worker, set a Content-Security-Policy response header for the request which delivered the worker script itself.

That is just one example extracted from this discussion in the Web Application Security Working Group GitHub repository.

Extracts of some comments there:

If you think that Content-Security-Policy is irrelevant for a particular document, and/or the server hasn't been configured to have a different CSP for a given response, then I would recommend sending Content-Security-Policy: base-uri 'none'; default-src 'none'. If you are using HTTP/2 then, after the first such response, this will be compressed to almost nothing for future responses.

If there is no Content-Type then browsers will do sniffing (sometimes). Thus you should generally assume the worst when there is no Content-Type header field. Thus Content-Security-Policy: base-uri 'none'; default-src 'none' is important when there is no Content-Type too, unless/until somebody writes down the specific rules for when omitting the CSP header field is safe.

(from briansmith)

Per @briansmith's recommendation of base-uri 'none'; default-src 'none' for when Content-Type is missing, I'd expand that policy to at least:

base-uri 'none';
default-src 'none';
form-action 'none';
frame-ancestors 'none'

As default-src only cover fetch directives.

(from Malvoz)

Upvotes: 1

Related Questions