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.
Related
Im getting a CSP violation in chrome console:
Refused to load the script 'https://ipinfo.io/?callback=jQuery....' because it violates the following Content Security Policy directive
even though ipinfo.io is included the policy.
script-src 'self' *.ipinfo.io;
Any ideas why ?
could it be because its a callback and not a static script ? could this be solved ?
but you allowed only subdomains, not your main domain.
*.ipinfo.io allows everything which is foobar.ipinfo.io but not the main Domain it self, you need to add it as well
I’m trying to add Content Security Policy to my Gatsby x Netlify website through a _headers file. Everything works fine, except for a Matterport iFrame that doesn’t want to be displayed. The error message I see in the console is
Refused to frame 'https://my.matterport.com/' because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'self'".
In my headers file, I added the following X-Frame-Options:
X-Frame-Options: ALLOW-FROM https://*.matterport.com/
And I also have this frame-src in my Content Security Policy:
frame-src 'self' https://www.youtube.com/ https://my.matterport.com https://matterport.com;
But the iFrames still look like this:
Matterport iFrames not displaying
Can someone help me figure out what I’m doing wrong here?
Thank you!
I recently came accross the same error message and corrected this by removing a double forward slash before the video link, my original iFrame inclusion looked like: https://my.matterport.com/show//?m=XXXXXXX replacing this with https://my.matterport.com/show/?m=XXXXXXX was enough to get the iFrame showing again.
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.
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.
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/