I think happened in the latest update of Chrome. They're not letting any of these content types if they come from a site. This is problematic because I need the chrome developer tools to develop my app making calls to an api. Does anyone know how to disable or override this?
Change the directory in cmd to "cd Program Files (x86)\Google\Chrome\Application"
and execute the below command to disable chrome security and also avoid "Blocked receiving cross-site document warning."
C:\Program Files (x86)\Google\Chrome\Application>chrome.exe --user-data-dir="C:/Chrome dev session" --disable-web-security --user-data-dir --disable-features=CrossSiteDocumentBlockingIfIsolating
We're using headless Chrome for an application testing. We have a page that refuses to redirect in headless mode but redirects perfectly fine when not running headless. The response header contains the URL to redirect to, and a 302 status code is returned.
What would cause Chrome to behave differently when running in headless mode? Is there any logging that would help me to determine why the redirect isn't working as expected?
Edit: Found some more info. It looks like I'm unable to redirect to sites with bad certs. How can I deal with ERR_CERT_AUTHORITY_INVALID when running Chrome in headless mode?
I was having the same issue and as you pointed out it happens with sites that have bad certificates. Passing the --ignore-certificate-errors flag didn't work at the time of the original post as there was a bug.
Some options to pass to have chrome-headless send more debugging info:
--log-level=0 --enable-logging --v=1 bug tracker for chrome/chromium headless not accepting the --ignore-certificate-errors flag:
bugs.chromium.org/p/chromium/issues/detail?id=721739 – karlos Dec 7
'17 at 20:15
For anyone reading now the bug was patched recently here: https://chromium.googlesource.com/chromium/src.git/+/c8f0691b18dc5d941d5b6b3c67a483da02400670
And the --ignore-certificate-errors flag should allow redirects to occur when using headless chrome for sites with bad certificates.
as to date seems like --enable-features=NetworkService solves the issue of self signed certificated in headless mode
I created a "packaged app" for Chrome browser and I do not want others to debug the app.
Is there a flag in the manifest or any other way to prevent debugging?
If you use native client and don't use any HTML/JS/DOM, except for loading the native client module, then you would not be able to debug very much with devtools.
I have a problem with the --disable-web-security flag. It is not working in Chrome 48 and Chrome 49 beta on Windows.
I've tried killing all of the instances, reboot and run Chrome with the flag first of all, tried different machines as well. In the beta I can see the warning popup ("You are using unsupported flag.."), but CORS is still being enforced. Public version seems to ignore the flag completely.
There seems to be no news or people reports about that, so it might be a local issue.
Will be grateful for help or any related info.
Update 2021-10-18
As of Chrome 95, on MacOS and Windows, --disable-site-isolation-trials remains a required flag in order to disable web security, so the command-line arguments to Chrome seen below are still valid. (Some of the arguments are not formally supported by Chrome, as it will warn you.)
To test whether you've successfully launched Chrome with web security disabled, run the snippet in Web Security Test at the bottom of this post.
Update 2020-04-30
As of Chrome 81, it is mandatory to pass both --disable-site-isolation-trials and a non-empty profile path via --user-data-dir in order for --disable-web-security to take effect:
# MacOS (in Terminal)
open -na Google\ Chrome --args --user-data-dir=/tmp/temporary-chrome-profile-dir --disable-web-security --disable-site-isolation-trials
# Windows (from "Run" dialog [Windows+R] or start menu in Windows 8+)
chrome.exe --user-data-dir=%TMP%\temporary-chrome-profile-dir --disable-web-security --disable-site-isolation-trials
(Speculation) It is likely that Chrome requires a non-empty profile path to mitigate the high security risk of launching the browser with web security disabled on the default profile. See --user-data-dir= vs --user-data-dir=/some/path for more details below.
Thanks to #Snæbjørn for the Chrome 81 tip in the comments.
Update 2020-03-06
As of Chrome 80 (possibly even earlier), the combination of flags --user-data-dir=/tmp/some-path --disable-web-security --disable-site-isolation-trials no longer disables web security.
It is unclear when the Chromium codebase regressed, but downloading an older build of Chromium (following "Not-so-easy steps" on the Chromium download page) is the only workaround I found. I ended up using Version 77.0.3865.0, which properly disables web security with these flags.
Original Post 2019-11-01
In Chrome 67+, it is necessary to pass the --disable-site-isolation-trials flag alongside arguments --user-data-dir= and --disable-web-security to truly disable web security.
On MacOS, the full command becomes:
open -na Google\ Chrome --args --user-data-dir= --disable-web-security --disable-site-isolation-trials
Regarding --user-data-dir
Per David Amey's answer, it is still necessary to specify --user-data-dir= for Chrome to respect the --disable-web-security option.
--user-data-dir= vs --user-data-dir=/some/path
Though passing in an empty path via --user-data-dir= works with --disable-web-security, it is not recommended for security purposes as it uses your default Chrome profile, which has active login sessions to email, etc. With Chrome security disabled, your active sessions are thus vulnerable to additional in-browser exploits.
Thus, it is recommended to use an alternative directory for your Chrome profile with --user-data-dir=/tmp/chrome-sesh or equivalent. Credit to #James B for pointing this out in the comments.
Source
This fix was discovered within the browser testing framework Cypress: https://github.com/cypress-io/cypress/issues/1951
Web Security Test
Run this snippet to confirm that this solution actually disabled web security in Google Chrome:
window.addEventListener("DOMContentLoaded", () => {
const iframe = document.querySelector("iframe");
iframe.addEventListener("load", () => {
const canAccessIframeDocument = !!iframe.contentDocument;
document
.querySelector(
canAccessIframeDocument ? ".security-disabled" : ".security-enabled"
)
.classList.remove("hidden");
});
// To ensure the `load` event always fires, only set iframe src after the
// event listener is attached.
iframe.src = "https://google.com";
});
body {
font-family: sans-serif;
}
.hidden {
display: none;
}
/* Web security should normally be enabled, so this is colored green, despite
the objective of this solution to disable it. */
.security-enabled {
font-weight: bold;
color: darkgreen;
}
.security-disabled {
font-weight: bold;
color: darkred;
}
<h1>Web Security Test</h1>
<p>
This test attempts to access the inner contents of a cross-origin iframe,
which is normally disallowed.
</p>
<p class="security-enabled hidden">
Web security is enabled. The cross-origin iframe document could not be
accessed.
</p>
<p class="security-disabled hidden">
Web security is disabled. The cross-origin iframe document was
successfully accessed.
</p>
<iframe class="hidden">
Iframes are not supported.
</iframe>
I'm seeing the same thing. A quick google found this question and a bug on the chromium forums. It seems that the --user-data-dir flag is now required.
Edit to add user-data-dir guide
Mac OS:
open -a Google\ Chrome --args --disable-web-security --user-data-dir=
UPD: add = to --user-data-dir because newer chrome versions require it in order to work
On OS X, to open a new Chrome window - without having to close the already open windows first - pass in the additional -n flag. Make sure to specify empty string for data-dir (necessary for newer versions of Chrome, like v50 something+).
open -na /Applications/Google\ Chrome.app/ --args --disable-web-security --user-data-dir=""
I found that using Chrome 60+ on Mac OS X Sierra, the above command no longer worked, but a slight modification does:
open -n -a /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --args --user-data-dir="/tmp/chrome_dev_sess_1" --disable-web-security
The data directory path is important. Even if you're standing in your home directory when issuing the command, you can't simply refer to a local directory. It needs to be an absolute path.
The chosen answer is good, but for those who are still struggling with what they are talking about(your first time dealing with this issue), the following worked for me.
I created a new shortcut to Chrome on my desktop, right clicked it, and set the "Target" field to the following,
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir="c:/chromedev"
The directory can be anything you want, I decided to make an empty folder called chrome dev in my C: directory. It has nothing to do where chrome is installed on your computer. It's just a fluff type thing.
This link also has clear directions for other OSes. How to disable web securityin Chrome
The version 49.0.2623.75 (64-bit) is not in beta anymore.
The command to fix the CORS issue is
google-chrome-stable --disable-web-security --user-data-dir
Install This Chrome-plugin for Disable-web-security in Chrome::
" Allow-Control-Allow-Origin: * "
link Here or you can google above plugin if you want.
it is very easy to enable and disable the security with this plugin.
For Chrome Version 50+ for Mac Users. Close all opened chrome first and run the below command
open -a Google\ Chrome --args --disable-web-security --user-data-dir=""
The above will work. Thanks
For Mac, using Safari is a good alternate option for local development purpose and the feature is built into the browser (so no need to add browser extension or launch Chrome using bash command like [open -a Google\ Chrome --args --disable-web-security --user-data-dir=""].
To disable cross origin restriction using Safari (v11+): From menu click “Develop > Disable Cross Origin Restriction”.
This does not require relaunching the browser and since its a toggle you can easily switch to secure mode.
From Chorme v81 the params --user-data-dir= requires an actual parameter, whereas in the past it didn't.
Something like this works fine for me
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir="\tmp\chrome_test"
In a terminal put these:
cd C:\Program Files (x86)\Google\Chrome\Application
chrome.exe --disable-web-security --user-data-dir="c:/chromedev"
As of the date of this answer (March 2020) there is a plugin for chrome called CORS unblock that allows you to skip that browser policy. The 'same origin policy' is an important security feature of browsers. Please only install this plugin for development or testing purposes. Do not promote its installation in end client browsers because you compromise the security of users and the chrome community will be forced to remove this plugin from the store.
For MacOSX
open -n -a /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --args --user-data-dir="/tmp/chrome_dev_sess_1" --disable-web-security
For Windows 10+
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --disable-gpu --user-data-dir=~/chromeTemp
It working for me.
Try using this..it will help you out..
c:\Program Files\Google\Chrome\Application>chrome.exe --disable-web-security --user-data-dir="D:\chrome"
For Windows
C:\Program Files\Google\Chrome\Application> .\chrome.exe --disable-web-security --disable-gpu --user-data-dir=~/chromeTemp
so, have web-site configured for ADFS 2.0 authentication...
for IE - it works fine and did authentication correct
for Chrome - it reaches redirect to AD FS server... ask to authenticate but could not authenticate.
I try to requests using fiddler but it show nothing interesting - so show that we redirect to adfs for authentication but nothing more
what it could be? why it is impossible to authenticate for chrome
thanks
In the event viewer you will see an 'Audit Failure' event with "Status: 0xc000035b". You can circumvent this problem by switching off 'Extended Protection' for the adfs/ls web application.
There are several articles on the Web on this, for example the "0xc000035b error during windows integrated login" thread on Microsoft's AD FS forum. Quoting:
To turn Extended Protection off, on
the AD FS server, launch IIS Manager,
then, on the left side tree view,
access Sites -> Default Web Site ->
adfs -> ls. Once you’ve selected the
"/adfs/ls" folder, double-click the
Authentication icon, then right-click
Windows Authentication and select
Advanced Settings… On the Advanced
Settings dialog, choose Off for
Extended Protection.
This issue occurs in several situations that I know of: when using Firefox 3.5+ or Chrome, using some specific NTLM configuration for which I don't have the details at hand, and when using Fiddler (see the "AD FS 2.0: Continuously Prompted for Credentials While Using Fiddler Web Debugger" TechNet article post, and the "Fiddler and Channel-Binding-Tokens" blog post which contains more technical background information).
(Note that nowhere I could find any information how to make NTLM authentication to AD FS from, e.g., Google Chrome and Firefox 3.5+ work without switching off 'Extended Protection'. I mean, Internet Explorer works with 'Extended Protection', why don't Chrome or Firefox? Or is this a Chrome/Firefox implementation bug/restriction, e.g., in their use of the Windows NTLM library?)
From Microsoft: http://technet.microsoft.com/en-us/library/hh852537.aspx
Unless and until Firefox, Google Chrome, and Safari support Extended
Protection for Authentication, the recommended option is to install
and use Internet Explorer 10 or later. If you want to use single
sign-on for Office 365 with Firefox, Google Chrome, or Safari, there
are two other solutions:
(1) Uninstall the Extended Protection patches
from your computer. (2) Change the Extended Protection setting on the
Active Directory Federation Services 2.0 server. See
“ExtendedProtectionTokenCheck” on the TechNet Set-ADFSProperties page
for details.
Switching off extended protection is not the answer. You add chrome as so adfs can recognize it and then add the site to the trusted list.
Make sure chrome is supported by adfs.
So, if you run the following commands:
$a=Get-Adfsproperties
$a.WIASupportedUserAgents
Then you add chrome to the list.
Set-ADFSProperties -WIASupportedUserAgents #("MSIE 6.0", "MSIE 7.0", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0", "Trident/7.0", "MSIPC", "Windows Rights Management Client", "Mozilla/5.0")
Now, we will need to tell the Chrome that it should allow Windows Integrated Auth for the site.
To do this, you will need to go to the settings:
Click on Advanced
Click on Proxy settings
It should open your IE Properties. Click on Security & Select "Local Intranet" and add the Federation service name of your ADFS here.
Click close and Apply under IE Properties.
Restart Chrome and next time when you try to access the site, it won't ask you for credentials.
This was a solution presented at work to allow SSO with Chrome WITHOUT disabling Extended Protection. Cheers for MS support.