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.
I find the best way to do this is duplicate a Chrome or Chrome Canary shortcut on your windows desktop. Rename this shortcut to "NO CORS" then edit the properties of that shortcut. in the target add --disable-web-security --user-data-dir="D:/Chrome" to the end of the target path.
In Windows - Right Click (or Shift+right click, in-case of taskbar) on Chrome Icon. Select Properties. In "Target" text-box, add --disable-web-security flag. Click Ok and launch chrome.
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.
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.
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.
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
--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.
This fix was discovered within the browser testing framework Cypress: https://github.com/cypress-io/cypress/issues/1951
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With