I have a problem loading YouTube thumbnails on Firefox, the images are blocked while on Chrome, it works fine. On Firefox I get the error NS ERROR INTERCEPTION FAILED in the network tab from the developer tools and if I remove my CSP in my htaccess file, those images are loaded correctly.
My CSP looks like this:
Header set X-XSS-Protection "1; mode=block"
Header always append X-Frame-Options SAMEORIGIN
Header set X-Content-Type-Options: "nosniff”
Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' 'unsafe-eval' https://*.laurentwillen.be https://*.googleapis.com https://*.googletagmanager.com https://www.google-analytics.com/ https://www.google.com https://cse.google.com https://*.gstatic.com https://*.youtube.com/ https://*.mobilemultimedia.be"
Header set Referrer-Policy "same-origin"
and the call to the image looks like this:
<img src="https://img.youtube.com/vi/xSbxgNuBfR0/0.jpg" alt="youtube_preview" width="100%">
Do you know how I could go around this and make Firefox load those images just like Chrome?
Thanks
Related
Related: Why is script-src-elem not using values from script-src as a fallback?
I am seeing a low of CSP reports where e.g. https://track.adform.net/serving/scripts/trackpoint/async/ is blocked due to the effective directive script-src-elem. As you can see in the policy below I am not defining script-src-elem but expect it to fall back to script-src or even default-src. That is my in my debugging this policy looks the way it does.
I have not been able to reproduce the report myself.
Full report:
{
"csp-report": {
"document-uri": "https://www.example.com/some/uri",
"effective-directive": "script-src-elem",
"original-policy": "default-src 'self' data: fonts.gstatic.com *.googleapis.com browser.sentry-cdn.com *.youtube.com i.ytimg.com sentry.io images.prismic.io *.atdmt.com *.adnxs.com *.google.se *.google.com *.facebook.com connect.facebook.net *.hotjar.com hotjar.io *.hotjar.io *.adform.net www.google-analytics.com www.gstatic.com www.googletagmanager.com stats.g.doubleclick.net;script-src 'self' 'unsafe-inline' 'unsafe-eval' data: fonts.gstatic.com *.googleapis.com browser.sentry-cdn.com *.youtube.com i.ytimg.com sentry.io images.prismic.io *.atdmt.com *.adnxs.com *.google.se *.google.com *.facebook.com connect.facebook.net *.hotjar.com hotjar.io *.hotjar.io *.adform.net www.google-analytics.com www.gstatic.com www.googletagmanager.com stats.g.doubleclick.net;style-src 'self' 'unsafe-inline' data: fonts.gstatic.com *.googleapis.com browser.sentry-cdn.com *.youtube.com i.ytimg.com sentry.io images.prismic.io *.atdmt.com *.adnxs.com *.google.se *.google.com *.facebook.com connect.facebook.net *.hotjar.com hotjar.io *.hotjar.io *.adform.net www.google-analytics.com www.gstatic.com www.googletagmanager.com stats.g.doubleclick.net;img-src 'self' * data:;report-uri https://example.report-uri.com/r/d/csp/reportOnly",
"blocked-uri": "https://track.adform.net/serving/scripts/trackpoint/async/"
}
}
I am only seeing it in the chrome browser on primarily Windows. There is a bug [1] report in the Chromium tracker but that was closed off without further investigation and seem to affect something else.
Is there something wrong with my policy or perhaps a bug should be opened in the tracker again?
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=880816
Script-src-elem being reported although script-src is defined
Chrome acts strongly with comply to CSP3 spec, it reports the violated-directive as effective-directive. Chrome sends effective-directive where violation should occurred if such directive will be presented in the policy.
Firefox despite CSP3 spec does send a really violated-directive as it appears in the policy. This will contain the default-src directive in the case of violations caused by falling back to the default sources when enforcing a directive.
The browser console always displays the actually violated directive as it present in the policy.
Therefore in case of policy:
default-src 'none'
Chrome sends a script-src-elem for <script> and <script src=>, and sends a script-src-attr for inline event handlers and javascript:-navigation, except one bug (this bug does not touch your CSP since inline scripts are allowed).
Forefox sends a default-src in the violation report.
Whose behaviour is more useful is an open question, but I prefer Firefoxes one. Because Chrome can make crazy anyone who looking for the cause of violations in the case of a long chain of fallback directives, such as in the case of the Worker, especially when some browsers skip some fallback directives in this chain.
So here we don't even need to "go to the doctor", in your case the script-src is really used for any scripts.
The right question is why https://track.adform.net/serving/scripts/trackpoint/async/ is occasionally blocked in the script-src directive despite the *.adform.net source is specified in it.
Since the situation cannot be reproduced, the only way is analyze the statistics - user agents and IPs.
If IP belongs to public hosting, you can just ignore such violations - it's a bots.
If is blocking the only one URL https://track.adform.net/serving/scripts/trackpoint/async/, it could be some browser "privacy" extensions like mentioned here, because this URL is a tracker.
Is the browser.sentry-cdn.com source mean you use a sentry? Does sentry shows the CSP errors? It should catch those, because CSP violations has built-in javascript errors handlers via SecurityPolicyViolationEvent.
PS: I have met only one odd "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36" which blocked all HTTPS: sources. As as it was seen from the original-policy, this user agent just removes all https:// from the policy.
Is there something wrong with my policy or perhaps a bug should be
opened in the tracker again?
I do not see anything wrong in your CSP. Anyway it should NOT lock https://track.adform.net/serving/scripts/trackpoint/async/.
IMHO to open a bug it need collect some specifics.
I've just started seeing this with my embedded youtube videos on Chrome (86.0.4240.193 - recently updated which is probably why I'm just seeing this) - these are 'reports' only, so the videos still show but 100s of errors can't be right! This is what I'm seeing:
[Report Only] Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'strict-dynamic' 'unsafe-inline' https: 'report-sample' 'nonce-t9IE7nI2leo7qKxsm7d80g=='".
Here's my iFrame --
<iframe id="video-iframe" width="500" height="281" src="https://www.youtube.com/embed/HIDDENVIDEO" frameborder="0" allowfullscreen ></iframe>
I cannot figure out what the CSP should be -- here's one that I found that apparently solved their problem --
<iframe id="video-iframe" width="500" height="281" src="https://www.youtube.com/embed/HIDDENVIDEO" frameborder="0" allowfullscreen csp="script-src 'self' https://www.google-analytics.com/ https://www.youtube.com/ https://s.ytimg.com/; object-src 'self'; child-src https://www.youtube.com/* https://s.ytimg.com/"></iframe>
Not so much -- I just see: Refused to display....
Any help much appreciated.
I just checked the developers.google.com/youtube/iframe_api_reference#Examples page and I'm seeing the same thing -- surely this shouldn't be happening, right?
As you can see, this error is triggered not your CPS - your's do not have 'nonce-t9IE7nI2leo7qKxsm7d80g=='" token. This error appears within Google's <iframe> and it's totally Google's internal deal.
The fact is that several previous versions of Chrome had a bug and did not block eval expressions.
In version 86 Chrome, they fixed this bug, and to verify this, they set the Report-Only header and made a fake call to eval to see reports.
CSP for Youtube is very simple and does not require 'unsafe-eval', because all works within isolated iframe:
frame-src youtube.com www.youtube.com; is enough to allow for Youtube in iframe.
By the way, your CSP has an error - the * is not allowed in path-part. And be careful with <iframe csp= - if server does not agree with your CSP, content will be blocked.
But this <iframe csp= played the role because of once more Chrome bug - it ignores Content-Security-Policy-Report-Only if Content-Security-Policy header presence.
I was able to get my embedded videos working using a meta tag in the <head>
<meta http-equiv="Content-Security-Policy"
content="default-src 'self'; img-src https://*; child-src 'none'; frame-src youtube.com https://www.youtube.com;">
add the https:// to www.youtube.com
Yes, another question about the CSP not loading a base64 image BUT I have researched a lot and can't find the solution. I have tried every configuration I've founded and still doesn't works.
So, what I'm trying is to load an Base64 image via Javascript.
var dataString = jQuery('#signature').jSignature('getData');
JQuery('#sig').append("<img class='imported' src='" + dataString + "'></img>");
As you can see it's not a big deal appending the base64 image (in localhost it works).
Then, searching about the CSP I found that the correct configuration to avoid the CSP with the Base64 Images is (and this is how I have the configuration):
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data:; font-src 'self' data:";
I have no problem with the font base64 but with the images it always throws this error:
Refused to load the image 'data:image/png;base64,...' because it violates the following Content Security Policy directive: "default-src *". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback.
Any ideas will be really appreciated, I really have no idea what is happening.
Have you tried as #Phonolog said. I have tried creating a plugin to support image url in importData rather than data-url-formatted.
Please check this post and see if it helps.
Create a jSignature plugin which sets the img src to the signature url.
inject the plugin
on importData remember to pass the plugin identifier
This way you can remove the data: from the csp header and self should be enough (img-src 'self')
My CSP policy is being ignored by the latest version of Chrome. I decided today to recreate the policy to try debug why, but as you can see from the error below, Chrome is advising me to add a hash that is already in the CSP (see sha256-idz8mDU5fJ8lJuEwY6hbkXVde/nqBBjQE/u5rxw1HUk=):
Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' https://pro.fontawesome.com/ 'sha256-LpfmXS+4ZtL2uPRZgkoR29Ghbxcfime/CsD/4w5VujE=' 'sha256-F+21FF3QOEHS5CNuMQEs3Q+LB0uULZF9DODEYnH/mMQ=' 'sha256-5uIP+HBVRu0WW8ep6d6+YVfhgkl0AcIabZrBS5JJAzs=' 'sha256-nK6A3vwzvwoN92MnHZrWtylYkYmW1jCQgTqWKQJNBMI=' 'sha256-idz8mDU5fJ8lJuEwY6hbkXVde/nqBBjQE/u5rxw1HUk='". Either the 'unsafe-inline' keyword, a hash ('sha256-idz8mDU5fJ8lJuEwY6hbkXVde/nqBBjQE/u5rxw1HUk='), or a nonce ('nonce-...') is required to enable inline execution.
This is working correctly in Firefox and Safari, so I'm thinking that there is something in my policy that is causing Chrome to stop reading values?
The content of my .htaccess file is:
Header set Content-Security-Policy "default-src 'none'; connect-src 'self'; font-src 'self' https://pro.fontawesome.com/; frame-src 'self'; img-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' https://pro.fontawesome.com/ 'sha256-LpfmXS+4ZtL2uPRZgkoR29Ghbxcfime/CsD/4w5VujE=' 'sha256-F+21FF3QOEHS5CNuMQEs3Q+LB0uULZF9DODEYnH/mMQ=' 'sha256-5uIP+HBVRu0WW8ep6d6+YVfhgkl0AcIabZrBS5JJAzs=' 'sha256-nK6A3vwzvwoN92MnHZrWtylYkYmW1jCQgTqWKQJNBMI=' 'sha256-idz8mDU5fJ8lJuEwY6hbkXVde/nqBBjQE/u5rxw1HUk=';"
Any advise is greatly appreciated.
I think this resource answers your question:
https://bugs.chromium.org/p/chromium/issues/detail?id=546106
The styles being blocked in the examples are styles in a style
attribute, Chrome only applies styles in style attributes when
'unsafe-inline' is set in 'style-src'. Safari behaves similarly but
Firefox does apply the styles if they match a hash in 'style-src'.
The CSP specification defines the hash and nonce exceptions only for
the and elements, not for the style and script
attributes so Chrome's behaviour seems to follow the spec. But the
error message generated in the console is incorrect (and confusing).
By the looks of it Chrome is following the CSP specification. I was facing the same issue with inline styles and seeing the same response as you, matching sha256 hashes! My solution has been to remove my inline styles and add them into my CSS to avoid inline styles completely.
While the console logged:
Refused to apply inline style because it violates the following
Content Security Policy directive: "style-src 'self'
'sha256-tLBf5MoZ1LfLjLmXgREJmfznfoX6mUwoWQJnC30N6JI='. Either the
'unsafe-inline' keyword, a hash
('sha256-tLBf5MoZ1LfLjLmXgREJmfznfoX6mUwoWQJnC30N6JI='), or a nonce
('nonce-...') is required to enable inline execution.
The solution would be to add 'unsafe-hashes', like so: style-src 'self' 'unsafe-hashes' 'sha256-tLBf5MoZ1LfLjLmXgREJmfznfoX6mUwoWQJnC30N6JI='.
See the 'unsafe-hashes' directive: https://w3c.github.io/webappsec-csp/#unsafe-hashes-usage
Safari 10 throws a CSP-style-src-Violation in spite of calling a weg page with no style attributes inside.
The violation-message is:
Refused to apply a stylesheet because its hash, its nonce, or
'unsafe-inline' does not appear in the style-src directive of the
Content Security Policy.
Test web page is:
CSP test page
The only addon installed is Adblock-Plus. After removing the addon, the violation is not shown anymore. The rendered html source shows no style-attribute at all, with adblock or without.
Is there a way how to filter out these false violation messages?
They are misleading.
I have also faced the same issue.looks like if you mention the style directive its expecting style-src 'self' 'unsafe-inline'; hope it helps.