I'm working with Firefox and I'm getting a lot of 'Content Security Policy' warnings in the the console,
including :
Content Security Policy: The page's settings blocked the loading of a resource at inline ("script-src").
and
Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified
I'm getting these warnings on every website, or almost every website, for example, I get a lot of warnings when I go to Gmail, and less here at StackOverflow,where some website show less, and some show more.
I have recently started working with webpack and some more nodejs tools, can this be the source of these warnings?
what can I do to prevent it?
is it a security issue?
thank you!:)
If I understand your question correctly, It appears you're approaching this as a user rather than as a developer.
From the user point of view:
what can I do to prevent it?
nothing, nor should you.
is it a security issue?
No. Quite the opposite, it is security at work protecting your browsing experience.
From the website developer point of view:
what can I do to prevent it?
Read up on the CSP rules put in place for your website(s) and adjust these rules as required to only allow what you need to alow for your website to work. This is a very broad topic.
I found the lack of clarification as to what assets are blocked and why, a major flaw with the Firefox console (V66) in that it didn't give enough specifity as to what CSP rules were crossed and what site assets were blocked. I found using Google Chrome console gave me this information and helped me to clarify my CSP to allow what needed to be allowed.
is it a security issue?
Not directly. This is security at work protecting the website visitor's browsing experience. Once the CSP is set up to allow the authorised parts of your website to work, the other parts that will be flagged by the CSP mechanism can be ignored (as insecure/unsafe things that should be aborted).
Related
I have switched to using Content-Security-Policy for my website. I'm starting to see reports about the following not being allowed: https://www.pagespeed-mod.com/v1/taas
Does anyone know why the website is trying to load this file? I'm using Google Analytics and Tag Manager, but I don't think that I have any page speed mod installed. Maybe this is an extension in the user's browser? Or when they open developer tools? Another source I could think of is automatic optimization through Cloudflare which I'm also running on.
Extra info: The source of loading this script is https://3001.scriptcdn.net/code/static/1 which doesn't reveal much about who made that.
Had the exactly the same issue and preventing me from using Element Inspector/ debugger. It appears to be some Chrome extension you have installed gone rogue, see if you have extension called "Auto Refresh Plus" installed like i did before.
I also see reports on https://www.pagespeed-mod.com/v1/taas being blocked with the same source of loading. It seems to happen in short periods on the various resources I have reports from. This indicates that it is related to the user/browser and not related to the site itself.
The same can be seen with translators, extensions, security proxies etc. I have given up trying to attribute the source of anything that is likely not caused by legitimate site content.
We recently made a number of changes to our CSP and have gotten reports from a very small number of users that the browser is not rendering because of one of these changes. We have 5 reports out of 2mil active users, so this is something very specific.
None of our QA are able to replicate this with their test browsers, so we're unable to determine what about the new CSP is causing the problem.
Is there a way to put a browser into some super strict mode so that it will stop all dynamic content with the slightest issue?
Rundown of my analysis:
I know the latest version also introduced some [tab] unicode, but I want to replicate this issue before I remove it so that I know that we've fixed it.
We do not have any of the deprecated X- headers in there.
Tried loading it into some online CSP validators but those come back with some vulnerabilities, but says the CSP is valid as written.
We're considering the report-to directive but have not implemented yet (Does anyone know if this would even help us in this?)
We were able to screenshare with one of the users with this issue and saw their browser console showing that it was stopping because of the CSP, but it had issues with the CSP that were very old. That user was running a current Chrome install
I'd post the csp but the invalid unicode wouldn't post anyway. It would also identify some of our clients.
I need to disable Chrome's iframe security for just one page so that I can access the contents of cross-domain websites.
I have complete control over this browser, this can use extensions.
I have been looking for a way to do this for the past hour or so. No luck.
You can try out this extension to bypass when development, this will allow you to resolve the issue with cross-domain issue:
https://chrome.google.com/webstore/detail/cross-domain-cors/mjhpgnbimicffchbodmgfnemoghjakai
Disclaim: I am the owner of this extension.
Does anybody have the same problem? New extension with verified domain and enabled inline install after clicking on button with chrome.webstore.install();cause redirect to chromestore with get parameter ?utm_source=inline-install-disabled
I recently received the following email from Chrome Web Store Developer Support:
In addition to the existing extension-level protection, our expanded
enforcement will also use machine learning to evaluate each inline
installation request for signals of deceptive, confusing, or malicious
ads or webpages. When we find those signals, we'll selectively disable
that one inline installation request and redirect the user to the
extension's page on the Chrome Web Store. This selective enforcement
will not impact inline installation of that extension from other,
non-deceptive sources. Developers will not be notified of this
enforcement, as it happens on an as-needed basis.
Are you serving any ads on your site or doing anything else that might be perceived as a grey area by ML?
If you're being blatantly deceptive, it would appear that you've been found out. If not, and you're genuinely confused, a possible first step would be to scrape your site of any ads or injected content altogether to see if you're able to regain Google's trust.
I'm currently doing front-end development for an insurance companies client portal and one of their developers is concerned about using typekit for security reasons. Does anyone know if there is a legitimate risk in using typekit on secure sites? Also, if anyone has some documentation on this that I could send to this developer that would be really helpful, I (surprisingly) wasn't able to find anything on the typekit site that would put his mind at ease.
Thanks!
There are different ways of including Typekit fonts. When you host your own CSS with #font-face rules pointing at font files on Typekit servers that's generally fine.
In this case Typekit will receive the URL of the page the user is browsing as a referrer, but there should not in general be sensitive information in the URL so that should be OK. (That may not be true if you have something like a reset password link - if you do, take care to ensure such URLs can only be accessed once so the ID in the link is worthless afterwards.)
However there is a variant where you include a script tag pointing at them:
<script type="text/javascript" src="https://use.typekit.com/some_id.js"></script>
This is a bad idea if your site does anything sensitive, because it gives typekit complete control over everything a user does on your site. If they went evil (or were compromised), they could steal any passwords typed on your site, delete all the user's data on the site, redirect the user to browser exploits, and so on.
In general you should never include remote scripts or stylesheets from anyone you don't 100% trust with the security of your site.
Any time you embed content, whether it be JS, CSS, fonts or anything else, from an external source to a sensitive page, you're increasing your attack surface. This does not necessarily mean that there is, or will be, a specific attack, but it does create more potential ways in which your site could be compromised.
Indeed, there have been real-world attacks using web fonts even without JavaScript, both based on browser / OS bugs and simply based on interactions of deliberate browser features. The Firefox security extension NoScript blocks CSS #font-face by default for that reason.
If you want to use a custom font on your secure site, the safest way to do it is to host it yourself — either on the site itself, or, perhaps better yet, from a separate no-cookie domain which is under your control, but isolated from your main website content by browser same-origin policies.