I upgraded Google Chrome to Version 64.0.3282.140 (Official Build) (64-bit) on a Windows 10 machine. Once I did, I am getting this error on my site within the developer tools console. Not real sure where to start. I did see a similar issue last year that was an issue with youtube (also in the url), but I haven't seen any solutions.
Error parsing header X-XSS-Protection: 1; mode=block;
report=https://www.google.com/appserve/security-bugs/log/youtube: insecure
reporting URL for secure page at character position 22. The default
protections will be applied.
16:07:31.905
I'm also seeing the issue when I go directly to youtube via the embedded url so it's not just on my site.
UPDATE
I've attached a photo of the headers in the response that indicate the google.com url that appears to be generating the issue.
It's a known bug in the current Google Chrome and Chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=807304
In the current version of their browser, the Chrome developers had restricted the X-XSS-Protection's report field URL to the same domain origin for some security reasons. So, when you embed a video with some embed code, as it downloads from another server where the header "report=https://www.google.com/" is set, and while your page is not hosted at the google.com domain - the error message occurs.
Yet, all minor sites (including youtube.com) are sending report URL with different origin domains in it. Probably, they are not even aware of this recent change in Chrome. So either YouTube will change their headers or Chrome developers will revert this. There's nothing that we, as end users, can do. Just wait till they sort this out.
UPDATE:
The issue has been fixed in Version 66.0.3359.117 (Official Build) (64-bit)
The issue has been fixed in Google Chrome new update.
Version 66.0.3359.117 (Official Build) (64-bit)
Make sure you have updated Chrome to this version.
Related
I'm developing a Firefox add-on which does block the malicious URLs. The problem is that sometimes Firefox render its own deceptive warning page and sometime it allows the extension to render its own warning page.
How can I bypass the deceptive page warning programmatically?
The above behaviour is working fine on Chrome.
Abdul Basit.
The easy way is with the privacy WebExtension API, here the documentation on the Mozilla Developer Network (MDN):
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/privacy
Access and modify various privacy-related browser settings. To use the
privacy API, you must have the "privacy" API permission.
You can already use services.safeBrowsingEnabled for Chrome, Opera, Edge, but Firefox not yet.
You can play around with the request status code 400, because it is related to the deceptive request routing.
Good luck.
I'm trying to grab data from one website and use it to write something into another website (using JQuery/Javascript). Understandably, the same origin rules weren't going to let that happen, but I figured disabling web security/CORS on my browser should fix that problem. For some reason, I can't get the policy disabled in Chrome, and I can't figure out why.
I've tried launching Chrome with --disable-web-security --user-data-dir=
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir="C:\Users\<username>\Desktop\chromeTemp"
I expected to be able to open a new tab, access 'document' in the console, and find a link I want to 'click', but instead I got
VM186:1 Uncaught DOMException: Blocked a frame with origin <url> from accessing a cross-origin frame.
I thought this would no longer be blocked?
Looks like there might be an open bug for this, possibly try an older chrome version.
https://bugs.chromium.org/p/chromium/issues/detail?id=840124
See Last Comment on workaround:
"The workaround is to download an old version of Chrome as a portable app : https://sourceforge.net/projects/portableapps/files/Google%20Chrome%20Portable/ (version 66.0.3359.181 still works). It's the one I use when I'm developing..."
After updating macOS at Sierra i noticed that jplayer is not working anymore
i get some javascript error that did not happen with previous safari version and are not display on firefox or chrome
[Error] Blocked script execution in 'http://www.mywebsite.com/' because the
document's frame is sandboxed and the 'allow-scripts' permission is not set. (x7)
i don't have a frame in my page
I'm using the circle button
http://jplayer.org/latest/demo-05/
on jplayer web site i don't get any error in my page i also have latest jPlayer
An issue has been posed at https://github.com/jplayer/jPlayer/issues/380
UPDATE
with macOS 10.12.1 the error message changed into
Sandboxing 'http://my.steam.com:5555/;stream/1' because it is using
HTTP/0.9.
i checked the HTTP response and it says
GET /;stream/1 HTTP/0.9
not sure if is possible to avoid sandboxing with HTTP/0.9
Why Google location services are not working? I already have the code which is working perfectly in browsers other than Chrome. It was working in Chrome till last Wednesday. And not only this, it is indeed not working for any other site who have used this code. Is this due to SSL?
As an example, please visit http://stores.hypethegym.com/hype-sector-4-gurgaon-339/Map
When you open this page, you should get a notification saying "Share your location" in firefox & IE10, but in Chrome, there is a problem.
We are getting following error in Chrome:
"getCurrentPosition() and watchPosition() are deprecated on insecure origins. To use this feature, you should consider switching your application to a secure origin, such as HTTPS...."
Thanks for the help in advance.
I get the following error in Chrome when loading a trivially simple html file with a jQuery Mobile reference. The error is not present with just the jQuery reference.
Uncaught SecurityError: Failed to execute 'replaceState' on 'History':
A history state object with URL 'http://stacksnippets.net/js' cannot
be created in a document with origin 'null'.
<html>
<head>
<script src="https://code.jquery.com/jquery-2.1.4.js"></script>
<script src="https://code.jquery.com/mobile/1.4.5/jquery.mobile-1.4.5.js"></script>
</head>
<body></body>
</html>
You can also "Run code snippet" and see the error in the console.
This error did not happen before today. I have not changed my code or method of loading the html file in the browser. It used to work perfectly - I use the same code for all my PhoneGap apps.
Does anyone know if there was a Chrome security update that causes this SecurityError or whether I'm missing something? How would you go about debugging this? Thank you.
UPDATE
This discussion I think points out what is going on, which I suspected, since the error does not appear when running with a web server: Origin null is not allowed by Access-Control-Allow-Origin .
But I am still wondering why this changed in the past day, whether Chrome has had a change in their security policy, or why it was working before, and whether any of my PhoneGap apps will be affected.
This error is same as the origin is null error. This error occurs because of the security feature of Chrome.
A simple solution to test the application is to bypass this security on chrome.
Steps:
create a chrome browser shortcut on desktop.
Close all the instances of chrome on your machine.
Right click on the desktop shortcut of chrome and click on Properties.
in Target field, append " -allow-file-access-from-files" at the end.
Save and close properties.
Open chrome via this shortcut only.
Hurry, the error has gone. App works perfectly.
NOTE: This is just a work-around I use to test my cordova apps on desktop browser for UI testing.
Temporary solution: I've commented out all history.replaceState calls in jquery mobile, didn't need to manipulate browser history in my app anyways.
I wonder if it's chrome security bug or model and future behavior.
On a Mac I was able to fix this by running a webserver instead of loading it from a "file://" url:
http://lifehacker.com/start-a-simple-web-server-from-any-directory-on-your-ma-496425450?utm_expid=66866090-49.VYy4WCNHSyuP6EmjnM93MQ.0&utm_referrer=https%3A%2F%2Fwww.google.com%2F
python -m SimpleHTTPServer 8000
In the directory should make it available from Chrome via 0.0.0.0
I don't seem to have the same problem, not on the stable version of Chrome (45) or the Dev version (47).
However, I have personally seen issues with the CORS header, too. If you can cause the problem to happen reliably, I suggest filing a bug at crbug.com and a Chrome developer will have a look at it.