Some weeks ago I noticed that our company's website (running Magento 2.4.5-p1) throws several CSP errors in the browser's console. As I am not a web dev, my understanding of coding is very limited, and haven't found any articles about this issue related to Magento 2.
While researching, I came across a business called Csper and using their free CSP policy evaluator I got a more detailed information about the errors. The report mentions that our policy uses the scripts 'unsafe-inline' and 'unsafe-eval' which they recommend not using because they can make the website vulnerable to XSS attacks.
So part of the suggestions of Csper are to remove these scripts, but at the same time they warn that this could require a refactoring of code. And here is my question: I am wondering if the CSP we have is a default Magento 2 script and if changing it could break something. If this is true, how could a default Magento script make the site vulnerable to XSS attacks?
And more importantly, how could I fix it? We currently use Google Analytics, Google Tag Manager and Facebook Ads as external services.
Any help will be highly appreciated. Thanks for your time.
Update:
I will append one of the errors for further details about the issue:
[Report Only] Refused to load the stylesheet 'https://fonts.googleapis.com/css?family=Open+Sans' because it violates the following Content Security Policy directive: "style-src *.adobe.com *.sagepay.com *.fontawesome.com unsafe-inline *.trustpilot.com tagmanager.google.com 'self' 'unsafe-inline'". Note that 'style-src-elem' was not explicitly set, so 'style-src' is used as a fallback.
You can create csp_whitelist.xml file in etc folder, i.e.
app/code/Vendorname/Modulename/etc/cps_whitelist.xml
You can add a domain to the whitelist for a policy like script-src, style-src, font-src and others by adding a csp_whitelist.xml to your custom module’s etc folder.
<? xml version = "1.0"?>
<csp_whitelist xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Csp/etc/csp_whitelist.xsd">
<policies>
<policy id="script-src">
<values>
<value id="uniqueId" type="host">example.com</value>
<value id="uniqueId" type="host">accounts.google.com</value>
</values>
</policy>
</policies>
</csp_whitelist>
this is more or less excessively described in the docs
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.
Im getting this error and I don´t know why, the scripts that I have included works?
And the error only shows up when I load a subpage. Not when I load the startpage.
So what Im I doing wrong?
The source list for Content Security Policy directive 'script-src' contains an invalid source: ''strict-dynamic''. It will be ignored.
<meta http-equiv="Content-Security-Policy" content="script-src * 'unsafe-inline' 'unsafe-eval' https://checkout.dibspayment.eu https://www.google-analytics.com https://maps.google.com;">
Any input really appreciated, thanks.
And the error only shows up when I load a subpage. Im getting this error and I don´t know why
The source list for Content Security Policy directive 'script-src' contains an invalid source: ''strict-dynamic''. It will be ignored.
It's not an error, just a warning that you browser does not support the 'strict-dynamic' token. (guess you use Safari).
I guess that subpage is a some Google's iframe (oAuth2, reCaptcha, etc). That iframe publush it's own CSP wich contains the 'strict-dynamic' token and this CSP was created in browsers backward compatibility mode (Google make such).
That's a warning from third-party CSP, not your's.
the scripts that I have included works?
Your parent page has own CSP which allows scripts. The CSP of nested browsing context (iframe) does not affects parent page (except the frame-ancestors directive).
So what Im I doing wrong?
Nothing. It's an intended regular work of Content Security Policy.
Each browsing context can have its own CSP. But all warns will flow to one browser console, and that is mislead.
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.
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 have been having problems with scripts not getting loaded because of problems with content security policy settings and was wondering if there was a way to set a content security policy so that it lets all websites be accessible for downloading scripts?
If you're not sure exactly what Content Security Policy you need, it's fine to start with a policy that's very permissive, (which is at least better than no policy at all) and refine it.
For example,
Content-Security-Policy: default-src 'self'; script-src *
would allow you to include scripts from anywhere, but everything else, for example images, only from your own site.
I would also recommend you start with Content-Security-Policy-Report-Only, which reports errors but doesn't block the content. That way you can safely test and refine your policy before you enforce it.
See for example Scott Helme's blog article
https://scotthelme.co.uk/content-security-policy-an-introduction/