Disable CORS in Chrome for local development

What --disable-web-security actually does

Chrome enforces the same-origin policy: JavaScript on one origin cannot read responses from another unless the server grants permission with CORS headers. The --disable-web-security flag turns that policy off for the entire browser profile. Cross-origin reads stop failing because the browser stops checking, so CORS errors, preflight failures, and opaque-response quirks all disappear at once.

Two details decide whether the flag works at all. It must be paired with a separate --user-data-dir, because current Chrome versions ignore --disable-web-security when it targets the default profile directory. And it only takes effect on a completely fresh instance: if any Chrome window or background process is already running, the new command just opens a window in the existing process and the flags are silently dropped.

Launch a CORS-disabled Chrome

1. Quit Chrome completely

   The flags apply only to a fresh process. On macOS quit with Cmd+Q, on Windows close every window and check the system tray for a lingering Chrome background process.

2. Launch with both flags

   Run the command for your operating system below. The --user-data-dir value is any empty directory; Chrome builds a throwaway profile there.

3. Verify the flags are active

   Open chrome://version and check the Command Line entry. If --disable-web-security is missing from it, Chrome was already running and ignored your launch arguments.

On macOS, launch Chrome through open with the flags after --args:

open -na "Google Chrome" --args --disable-web-security --user-data-dir=/tmp/chrome-dev

On Windows, call the executable directly from cmd:

"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe" --disable-web-security --user-data-dir=C:\\chrome-dev

On Linux, pass the flags to the browser binary:

google-chrome --disable-web-security --user-data-dir=/tmp/chrome-dev

Why this is risky

The flag does not relax CORS for your app alone. It disables the same-origin policy for every site loaded in that profile, and the same-origin policy is what stops a random page from reading your webmail, your bank session, or your company admin panel while you are logged in.

• Any site opened in the weakened profile can read responses from any other site, including authenticated responses if you sign in anywhere.
• The separate --user-data-dir is the only thing keeping the weakened browser away from your real cookies, sessions, and synced data. Never point it at your normal profile directory.
• Treat the profile as disposable: no account sign-ins, no everyday browsing, and close it when the debug session ends.
• If the flags were ignored because Chrome was already running, you hit the opposite failure: nothing changed and you debug a phantom. Always confirm on chrome://version.

Better alternatives for daily development

Disabling web security works, but it changes your browser instead of fixing the request path. Three options solve the same problem without weakening anything:

• Proxy through your dev server. The Vite dev server proxy forwards API calls server-side, so the browser only ever talks to its own origin and no CORS check applies. The configuration lives in your repo and works for the whole team.
• Fix the server when you own it. If the target API is yours, return the correct Access-Control-Allow-Origin headers from it. That is the only fix that also holds in production.
• Use a public proxy for third-party public APIs. When the API is not yours and sends no CORS headers, prefix it with a public CORS proxy that re-serves the response with the headers the browser needs. Public data only: the proxy operator can observe the traffic.

Good questions.