Mozilla Observatory used to rate my managed WP site as A+, but currently returns it at B, with 25 points deducted as “Content Security Policy (CSP) header cannot be parsed successfully.” The CSP still gets an A+ at <securityheaders.com>.
My CSP’s script-src directive includes a strict-dynamic value with no nonce or hash values as I have yet to read up properly how to generate those. Could that be the issue, as it maybe stops all script use?
Related
I am trying to add CSP to our web site, using report-only (to report-uri.com).
It seems to work as expected for most cases, but google related sites gets reported even if the URL is added to the header.
Here´s the relevant part of header as it appears in developer tools:
connect-src 'self' https://stats.g.doubleclick.net
I am still getting this violation:
"blocked-uri": "https://stats.g.doubleclick.net/j/collect"
I have experienced similar issues with other Google related sites as well.
The problem is that we're using Google tags and analysis, so I cannot block the sites out.
This particular problem seems to come from Chrome only.
In addition to blocked-uri, note in the reports on the original-policy field - is there your CSP with the connect-src 'self' https://stats.g.doubleclick.net rule or not.
Looks like some ISPs, in violation of RFCs, cache site responses along with HTTP headers. At least after the changes in the CSP, within 2 weeks there is violation reports having the old CSP in the original-policy field.
And it feels like you changed the rules in connect-src directive recently.
List of sources connect-src 'self' https://stats.g.doubleclick.net is not complete for Google Analytics, you can insert own Google Analytics ID and check. Here is comprehensive test of Content Security Policy for GTM.
Here is initial CSP for GA + GTM. The initial because though GTM you can embed a lot of third-party scripts from vary sources.
When implementing csp-header, I have specified my policy as:
default-src 'self'; script-src www.gstatic.com; Since I have not declared script-src-elem directive in my csp policy, as stated in this mdn documentation, I was expecting policy defined for script-src to be used for script-src-elem directive as well. However, I see violation being reported as "violated-directive":"script-src-elem" "blocked-uri":"https://www.gstatic.com/blah/blah".
Any idea why this behavior is happening?
After seeing this exact same pattern in some of my applications, I finally got to the root of this!
The weirdness we were seeing was that CSP reports were coming in for a hostname which was definitely in the script-src directive; and we know that script-src-elem is supposed to fall back to those directives. From that perspective, it should have been literally impossible for these reports to happen.
Here's what we found: the users these reports were coming from were using the PrivacyBadger browser extension, which was leading to false positive CSP reports for the hosts (Google) that it blocked. I didn't dig too far into it, but here's my theory on how that happens:
The Content Security Policy performs a pre-request check for the JavaScript include on the page (eg. gstatic.com or google-analytics.com). The pre-request check passes, because the hostname is allowed in the policy.
The browser initiates a request for the resource
PrivacyBadger intercepts the request via the browser's onBeforeRequest API (see PrivacyBadger source and Chrome documentation)
ProvacyBadger returns a surrogate data blob for the asset. It does this to ensure that code which relies on the real javascript (eg. window.ga) won't break.
The browser then performs a post-request check against the returned base64 blob
The post-request check fails - because the policy does not allow data: for script-src
The browser sends a CSP report for the blocked asset.
This seems like it might be a browser bug - because the report reflects the original asset's third party hostname; while the blocked content is actually a data: blob that was returned via the intercepted request.
From the documentation you linked to: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src-elem
The HTTP Content-Security-Policy (CSP) script-src-elem directive specifies valid sources for JavaScript elements, but not inline script event handlers like onclick.
Without seeing the rest of your code it is a safe assumption that you are seeing this error as a result of an inline event handler and will need to define script-src-elem in your CSP policy.
script-src-elem definitely does fallback to script-src in browsers on the Chromium engine. Check the Chrome console, the warn will looks like:
... Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.
Gecko-browsers does not support script-src-elem and use script-src directly.
The CSP2-browsers in violation reports sends a violatied directive resulting after all fallback chain. But CSP3-browsers send a "theoretically" violated directive and than perform fallback if directive was omitted. This introduces some confusion.
script-src-elem have nothing to do with inline event handler like onClick() -this is noted in MDN docs. script-src-elem controls only <script>...</script> and <script src='...'> elements (and javascript-navigation).
"blocked-uri":"https://www.gstatic.com/blah/blah" says that https://www.gstatic.com host-source was blocked, not inline event handler.
Inline event handlers do lock in the script-src-attr directive and report will looks like "blocked-uri":"inline".
Looks like you edit a copy CSP, but server issues another as default. Please look the "original-policy" filed in the report's JSON. Is it contains you real CSP or some default one?
PS: To detail analyse what's going on it need to look a full violation report and a your full CSP (print screen of browser console messages will be very helpful). Because script-src www.gstatic.com; is totally enough for CSP3-browsers to allow any resources from 'https://www.gstatic.com'. (CSP2-browsers requires more rules but you shown violation report sent by CSP3-browser).
I know I'm late to this, but this thread brought me to the solution for my case:
Disable the NoScript-Addon in Chrome.
We want to secure our site with Content-Security-Policy, and even with the setting of allowing inline scripts (default-src 'self'; script-src 'self' 'unsafe-inline'), loading modernizr (2.6.2) produces 4 CSP violations:
I upgraded to the latest version (3.6.0), the develop version, and now it produces over 30 CSP violations:
I couldn't find any official statement on CSP on the modernizr site, it merely mentions that in 2012, they added a detect for Content Security Policy (https://modernizr.com/news/modernizr-262).
Reading various blogs and Stack Overflow questions, I find most up-to-date best-practice from 2017 to be:
If modernizr is injecting all that inline stuff than it seems like
your choices are to either (a) add all those hashes, (b) use
'unsafe-inline' (but which basically defeats the whole purpose of
CSP…), or (c) don’t use modernizr.
Although, the errors I am getting occur even when using unsafe-inline.
Has anyone found a workable solution to using both Content-Security-Policy and modernizr?
Try using this lenient CSP default-src * 'unsafe-eval' 'unsafe-inline' 'unsafe-dynamic' data: filesystem: about: blob: ws: wss: and start removing keywords until you start getting errors, with this method you can adjust your CSP to your needs.
It would be nice if there was some sort of CSP generator where you give it a website and it just knows which CSP you need in order to not keep erroring.
Remember that * means allow all domains, so replace this with all domains you intent to support.
This of course just fixes, or solves the issue, and it depends what it's at stake, what content does your website offer, and how vulnerable would users be if an XSS attack could be carried through. CSP protects merely against XSS attacks, this is just JavaScript that could be inserted by a third party, using HTTPS for example, will make it almost impossible for a MITM to inject arbitrary code.
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.
Content Security Policy specification says
The frame-ancestors directive obsoletes the X-Frame-Options header. If a resource has both policies, the frame-ancestors policy SHOULD be enforced and the X-Frame-Options policy SHOULD be ignored.
So from my understanding if both Content-Security-Policy and X-Frame-Options headers are present, then X-Frame-Options should be ignored.
I have a web app with both headers, and looks like Firefox 38 is ignores Content-Security-Policy header and uses X-Frame-Options header instead.
My sample headers are:
Content-Security-Policy:frame-ancestors 'self' local.com *.local.com
X-Frame-Options:Allow-From http://local.com
I want that my frame should be accessed from local.com and all subdomains. Local.com is just example. If X-Frame-Options header is present, then it allows just http://local.com, but if i remove it, then Firefox uses Content-Security-Policy header and works fine for domain and subdomains.
Does it mean that Firefox isn't implementing this part? Or it's just too new specification and Firefox doesn't implement it yet? Is there any other way to force Content-Security-Policy header usage?
I know that Chrome works fine with Content-Security-Policy and IE can work just with X-Frame-Options, but looks like i can't combine both headers, as Firefox works not in right way.
One possible way is to sent X-Frame-Options just for IE, and Content-Security-Policy for all other, but is there a better way?
Thanks!
frame-ancestors only appeared in CSP Level 2 (see the changelog) so it's very likely that Firefox 38 just hasn't implemented it yet.
You can verify that quite easily by watching the JavaScript console - the browser will display warnings about each of the CSP directives it doesn't understand.
You can also download Firefox from the beta channel and see if it makes difference, but obviously it won't help much if you just want to build a interoperable solution for production website...