/flags/cors/chrome-disable-web-security
chrome --disable-web-security --user-data-dir: turn off CORS for local testing
- tool
- CORS
- command
- chrome
- flag
- --disable-web-security --user-data-dir=DIR
- default
- off (the same-origin policy and CORS checks are enforced)
Starting Chrome or Chromium with --disable-web-security --user-data-dir=/tmp/chrome-dev launches a browser instance that does not enforce the same-origin policy, so cross-origin fetch() and XHR responses can be read even when the server sends no CORS headers. Chromium's own source describes the switch as "meant for website testing only" and states that it has no effect unless --user-data-dir is also present. Use it for a quick local experiment, never for everyday browsing, and fix the real problem on the server.
How to start it
The browser must start as a new process with a separate profile directory. Close nothing else; just point it at an empty directory:
google-chrome --disable-web-security --user-data-dir="$(mktemp -d)" --no-first-run http://localhost:3000open -na "Google Chrome" --args --disable-web-security --user-data-dir="$(mktemp -d)" --no-first-run& "C:\Program Files\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir="$env:TEMP\chrome-dev" --no-first-runA warning bar ("You are using an unsupported command-line flag") confirms that the switch was accepted.
Why it seems not to work
| Symptom | Cause | Fix |
|---|---|---|
| CORS errors still appear | --user-data-dir is missing, so Chromium ignores the switch | Add --user-data-dir with a new directory |
| A tab opens in the existing window, no warning bar | A Chrome process already uses that profile and received the URL | Use a directory no running Chrome uses |
| Works in Chrome, not in Firefox | The switch is Chromium-specific | Use the Chromium-based browser for the test |
| Cookies are still not sent | SameSite and third-party cookie rules are separate from CORS | Test cookies with a correctly configured server |
What it changes, and the risk
The switch turns off the same-origin policy for every page in that browser instance: any site you open in it can read responses from any other origin, including sites where that profile is logged in. That is why it requires a throwaway profile, and why you should not sign in to real accounts or browse the web with it.
Better alternatives
- Send the right headers. Add
Access-Control-Allow-Originon the API, for example with the Express cors middleware; the browser error No 'Access-Control-Allow-Origin' header lists the cases. - Proxy through the dev server. Vite, webpack and Angular dev servers can forward
/apito the backend, which makes the request same-origin, so CORS does not apply. - Test the API without a browser. curl does not enforce CORS; test CORS with curl shows how to send the
Originheader and read the response headers a browser would check. - Credentials. If the error mentions the wildcard, the server must echo the exact origin; see wildcard origin with credentials.
FAQ
Why does --disable-web-security do nothing?
Chromium ignores the switch unless --user-data-dir is also given, and a Chrome window that is already running with the same profile simply receives the new tab instead of starting with your flags. Use a new, empty directory for --user-data-dir.
Can I disable CORS for one site only?
Not with this switch: it disables the same-origin policy for the whole browser instance. To limit the effect, fix the server headers, use a dev-server proxy so the request becomes same-origin, or test with curl, which does not enforce CORS.
Does the flag work in Edge, Brave and other Chromium browsers?
The switch is defined in Chromium's content layer, so Chromium-based browsers accept it with the same --user-data-dir requirement. Firefox has no equivalent command-line switch.