Question is regarding having CSP served twice:
What's the behavior if there is one policy served through the Content-Security-Policy HTTP response header and also another policy specified with the <meta /> element?
Will those two be merged somehow? Or else which one has priority? (I cannot find clear info on this in the spec).
Specific use case might be serving Report-to through the HTTP response header and putting all other restrictions in the <meta /> element — because some of those are generated by webpack - and if I shouldn't be worried about <meta /> shallowed by the HTTP response-header policy.
If you have CSP directives specified both in a Content-Security-Policy HTTP header and in a meta element, the browser uses the most-restrictive CSP directives, wherever specified.
See the details on multiple polices at https://w3c.github.io/webappsec-csp/#multiple-policies and details on using the meta element at https://w3c.github.io/webappsec-csp/#meta-element:
A policy specified via a meta element will be enforced along
with any other policies active for the protected resource, regardless
of where they’re specified. The general impact of enforcing multiple
policies is described in §8.1 The effect of multiple policies.
8.1. The effect of multiple policies
The impact is that adding additional policies to the list of policies
to enforce can only further restrict the capabilities of the protected resource.
Related
I'm using Directus with editorjs extension and trying to embed a YouTube video, but I'm encountering a Content Security Policy error that is blocking the frame-src. The error message I'm getting is:
"Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”)."
I've tried adding the following setting in my .env file:
CONTENT_SECURITY_POLICY_DIRECTIVES__FRAME_SRC="array:'self', 'https://www.youtube.com'"
But I'm still encountering the same error.
There is likely a Content Security Policy present on your page, and adding another one can only make it stricter, not loosen any of the directives. First you'll likely need to locate the existing CSP, likely in a response header, find how it is set and modify it.
To fix the inline script violation you will need to add the hash of the inline script (some browsers will tell you the hash), add a nonce to the script, refactor it into a file or resort to adding 'unsafe-inline'. You should add your chosen source to script-src.
You should also add www.youtube.com to frame-src and/or child-src (frame-src will use a fallback to child-src in CSP level 3 and to default-src in CSP level 2.
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.
It is only necessary to apply it to web pages that are rendered in a browser, as CSP controls the allowed sources for content, framing etc of such pages. Typically you will only need to set it on non-redirect responses with content type as "text/html". As CSP can be set in a meta tag, another way to look at it is that it only makes sense on responses that could include a meta tag.
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.
i want to add content security policy header in tomcat.I am able to add x-frame header by changing webxml file.but i do not if i can add content security policy header in the same way.
please help on this
Using the web.xml file you can publish some security headers, for example X-Frame-Options, X-XSS-Protection, but not the Content-Security-Policy one.
Because web.xml config is based on built-in Tomcat filters which does not support CSP header yet. Therefore, you need to create custom servlet-filter, which can then be used in the web.xml file.
You can found some nitty-gritty about custom filter creation in the grails-x-frame-options-plugin, based on XFO header.
OWASP also has a detailed example of a CSP filter.
As far as I understand, there are two ways to specify the Content Security Policy:
On a server side via headers:
res.setHeader("content security-policy", "default-src: 'none';")
In an HTML-page via meta-tag:
<meta content = "default-src 'none';" http-equiv = "Content-Security-Policy" />
My questions:
What is the difference between these two techniques?
Is it enough to use just one of them?
Which one should I use? Backend, frontend, or both?
P.S. Thanks to How does Content Security Policy (CSP) work?, I know what is the CSP and how does it work. What I want to know, however, is where exactly it is better to set the CSP.
Delivering CSP via HTTP header is a preferred way.
Meta tag has the same functionality but for technical reasons it does not support some directives: frame-ancestors, report-uri, report-to and sandbox. Also the Content-Security-Policy-Report-Only is not supported in meta tag.
In SPA (Single Page Application), a meta tag is traditionally used for CSP delivery, because a lot of hostings do now allow to manage of HTTP header.
When SSR (Server Side Rendering), an HTTP header is used more often.
You can use any technically convenient CSP delivery method (keeping in mind the limitations of the meta tag), but do not use both at the same time. Both policies will be executed one after the other, so in case of differences, a stricter one will apply actually.
Note that:
CSP meta tag should be placed in <head>, otherwise it will not work.
Changing the meta tag by javascript will result in both the old and the new policies being in effect.
in cases of CSP for non-HTML files, the meta tag can not be used technically
I am working on addition of Content-Security-Policy-Report-Only header to my company's website. While I was researching on it, I found that a few of the pages already have Content-Security-Policy header set.
I investigated further and found that the directives are not required. Also, default directive used for those pages is 'self' whereas what I am planning to set for report-only is 'https:'
I am not an expert in this area and want to make sure that both header values don't interfere. Hence looking for guidance
If I set report-only for the pages that already has CSP header, is it going to interfere with existing headers? Is the behavior browser dependent?
Any help/pointers will be helpful in deciding.
Thanks!
Content-Security-Policy and Content-Security-Policy-Report-Only have no effect on each other and are entirely independent. Setting both is a common practice when tightening policies. I wouldn't doubt that there has been a bug around this behavior at some point, but the spec is clear.
From Section 5 of the CSP2 Spec
A server MAY cause user agents to monitor one policy while enforcing another policy by returning both Content-Security-Policy and Content-Security-Policy-Report-Only header fields. For example, if a server operator may wish to enforce one policy but experiment with a stricter policy, she can monitor the stricter policy while enforcing the original policy. Once the server operator is satisfied that the stricter policy does not break the web application, the server operator can start enforcing the stricter policy.
Based on the link here, server must not send both headers in the same request.
Here is the original text: A server MUST NOT provide Content-Security-Policy header field(s) and Content-Security-Policy-Report-Only header field(s) in the same HTTP response. If a client received both header fields in a response, it MUST discard all Content-Security-Policy-Report-Only header fields and MUST enforce the Content-Security-Policy header field.