I need to use Stripe in my application but I keep getting the error below in the browser console.
Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”).
I've tried to fix it by setting a rule in Content-Security-Policy but I cannot make it work.
<meta http-equiv="Content-Security-Policy"
content="script-src 'self' https://js.stripe.com />
<script type="text/javascript" src="https://js.stripe.com/v3/"></script>"
I run the code in localhost and I am using Firefox Developer Edition.
How can I fix this error?
To allow a script resource at inline, your CSP needs to have 'unsafe-inline' set. But as you can understand from the name, this is unsafe and should be avoided if possible. Rather see if you can move the script code to a separate file.
Also, it seems like you are hitting a problem with a CSP and try to solve it by adding another one. Another CSP can only make it stricter, you can't allow something restricted by the original CSP. You should see if there is a CSP in a response header and modify that one instead.
Related
I set some Content Security Policies on my website and it all seems to work as expected. However I have two tags including some stylesheets and I have added a random nonce to them:
<link rel="stylesheet" href="https://cdn.jsdelivr.net/gh/openlayers/openlayers.github.io#main/dist/en/v7.0.0/legacy/ol.css" type="text/css" nonce="#ViewData[Constants.ViewDataForRandomNonce]">
<!--webfonts-->
<link href='https://fonts.googleapis.com/css?family=Average+Sans' rel='stylesheet' type='text/css' nonce="#ViewData[Constants.ViewDataForRandomNonce]">
<!--//webfonts-->
When I open the page the resources seems to be loaded and all works as expected. However, if I open the DevTools of the Browser(Chrome/Firefox/Opera/Edge) errors that these resources are blocked appears:
Refused to load the stylesheet 'https://cdn.jsdelivr.net/gh/openlayers/openlayers.github.io#main/dist/en/v7.0.0/legacy/ol.css' because it violates the following Content Security Policy directive: "style-src 'self' 'nonce-tafkuumpf7umcwUlySiRUQI201ARRpx0a6woKsteas9hywtxVshmpJUREdoycXT5'". Note that 'style-src-elem' was not explicitly set, so 'style-src' is used as a fallback.
Refused to load the stylesheet 'https://fonts.googleapis.com/css?family=Average+Sans' because it violates the following Content Security Policy directive: "style-src 'self' 'nonce-tafkuumpf7umcwUlySiRUQI201ARRpx0a6woKsteas9hywtxVshmpJUREdoycXT5'". Note that 'style-src-elem' was not explicitly set, so 'style-src' is used as a fallback.
If I reload the page while the DevTools is open the error disappear. But as soon as I close and then open again the DevTools, the error appears.
This happens on Chrome, Firefox, Opera and Edge (I don't have any other browsers on my PC). On Firefox the errors don't disappear even after I reload the page.
One maybe important thing is that I am testing on the localhost, if that could be it.
Any ideas what might be happening?
I fixed this by adding the CDN addresses to the CSP list of allowed hosts. Kinda weird because it already had a nounce and it was working
The website works fine on all other browsers I've tested it on.
On the Brave browser, an error occurs for line 1 of my index.html file (Which is <!DOCTYPE html>):
Refused to load the font 'data:application/font-woff...' because it violates the following Content Security Policy directive: "default-src 'self' *.favicon.cc *.google.com *.gstatic.com *.googleapis.com". Note that 'font-src' was not explicitly set, so 'default-src' is used as a fallback.
Line 6 of my index.html is this: <meta http-equiv="Content-Security-Policy" content="font-src 'self' data:; default-src 'self' data: blob: 'unsafe-inline';">.
For some reason, this error only occurs on this .co domain, but when I host the same HTML file on other TLDs (I've tested: .ml, .gq, .dev) it works with no issue, using the CSP I set in the header.
Is there any way to get Brave to use the CSP I set in the file instead of the one Brave uses?
I've tried using it as an actual HTTP header, no change.
Edit for additional context: The entire page breaks as if the CSP is set to "default-src 'self' *.favicon.cc *.google.com *.gstatic.com *.googleapis.com" and other page elements do not load properly.
It turns out it's an issue with brave's shields. Disabling them fixed it. I have reported my site to Brave's developers so they can try and fix the problem. As for my site, i've switched to a .com domain from the original .co domain, and it works fine now.
My script-src for my website continues to produce an error and refuses to load my scripts which lie within my Header.html file, and I have tried multiple websites, including reading the docs, however I am unsure of what I am doing wrong of if I just need to be patient and wait for it to take effect on my site.
I am currently using a Meta tag for my CSP policy,
<meta http-equiv="Content-Security-Policy" content="default-src * 'unsafe-inline' 'unsafe-eval'; script-src * 'unsafe-inline' 'unsafe-eval';">
<script src='https://th4rjdmmrjsz.statuspage.io/embed/script.js'></script>
However, regardless of what I do with it nothing seems to work, I have used sites like RapidSec and the CSP site itself, including an auto generator, and nothing seems to have worked. What am I doing wrong here?
Edit: Added an example script.
CSP has versions (or levels) with newly supported features extending the original spec. Serving the CSP through an html meta header is considered legacy and has some drawbacks/bugs. Try setting CSP via the HTTP headers of the request.
Also, if you're using RapidSec, you can use the integrations (Wordpress plugin, Node.js package) that do this automatically for you.
I'm trying to run the default example code (using my Client ID) linked at:
https://developers.google.com/identity/sign-in/web/
The code runs correctly on Google Chrome browser (returning all user infos) while it throws an exception using Firefox:
"uncaught exception: [object Object]"
Can anyone help me?
Best Regards
Please delete all cookies from google and clear your cache then restart Firefox. If does not work go back into cookies and clear everything that you know you do not need. Also check your Firewall software see if anything adds up to google and can put a exemption in maybe. Also turn off any adblockers when go to the site.
If that does not work https://support.mozilla.org/en-US/kb/refresh-firefox-reset-add-ons-and-settings
In SSL case only; put in HEAD the following meta
<meta http-equiv="Content-Security-Policy" content="default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline' ">
Even though https: is specified in default-src, the script and style directives don't automatically inherit that source. Each directive completely overwrites the default for that specific type of resource.
If I have a CSP meta tag (as opposed to using an HTTP header), like so:
<meta http-equiv="Content-Security-Policy" content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'">
... and then I go into developer tools and remove that node, would the browser act as though it was never provided, or would the fact that it was added at all be persistent no matter what?
I'm asking because I want to know if I should use an HTTP header (which can't be modified), or if it's safe to just use this meta tag.
No. In the Content Security Policy spec it says:
Note: Modifications to the content attribute of a meta element after the element has been parsed will be ignored. [own markup]
I would read that as: "Once the meta tag's CSP is parsed, modifications to the tag (including deletions) will not effect the CSP".
But also note KayakinKoder's answer and make sure to place the meta tag at the very top of the head element:
Authors are strongly encouraged to place meta elements as early in the document as possible, because policies in meta elements are not applied to content which precedes them. In particular, note that resources fetched or prefetched using the Link HTTP response header field, and resources fetched or prefetched using link and script elements which precede a meta-delivered policy will not be blocked.
I definitely wouldn't put it in html. Even if you tell browsers to never cache thing X, some will eventually screw around and cache thing X "to be helpful". Lets say you want to change your CDN from example.net to differentcdn.com in the future; if any browsers have cached your CSP, your site will be broken. Or even worse, you accidentally edit the CSP CDN section to "exEmple.net" and deploy; browsers cache this, and your site is completely broken. We've had some users browsers cache 302 (temporary..) redirects that were clumsily put in an .htaccess file rather than completely server-controlled http.conf, what a nightmare; I don't trust browsers to do what they are supposed to do on anything extremely important that would break our app.
As far as I'm aware, headers are never cached.
Finally, I would recommend looking into Google's strict CSP 3: https://csp.withgoogle.com/docs/strict-csp.html
It looks like this Content-Security-Policy meta tag is "protected", i.e. the browser remembers its value even when it is removed via dev tools.
You can simply try it with this simple example:
index.html
<!DOCTYPE html>
<html lang="en">
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta http-equiv="Content-Security-Policy" content="default-src self;">
Then open dev tools and type in:
fetch('http://example.com')
You will see something like:
VM345:1 Refused to connect to 'http://example.com/' because it violates the following Content Security Policy directive: "default-src self 'mocky.io'". Note that 'connect-src' was not explicitly set, so 'default-src' is used as a fallback.
Let's try it with removing that particular meta tag
document.querySelector("[http-equiv='Content-Security-Policy']").remove()
fetch('http://example.com')
You will still see the same error.
I tried it in the most recent versions of chrome and firefox. Maybe some least known browsers or lower versions will react differently. Unfortunately, I couldn't find more info about it but I don't see any particular reason for not using it.