CORS Chrome extensions

What these extensions do

The popular options are free: "Allow CORS: Access-Control-Allow-Origin" has over 800,000 users on the Chrome Web Store, and "CORS Unblock" covers the same ground. Under Manifest V3 they run on the declarativeNetRequest API with modifyHeaders rules. Those rules rewrite HTTP response headers after the server answers but before the page sees the result, typically adding or overwriting Access-Control-Allow-Origin: * on every response so the browser's CORS check passes and fetch resolves.

# What the server actually sent
HTTP/2 200
content-type: application/json

# What your page sees after the extension rewrites headers
HTTP/2 200
content-type: application/json
access-control-allow-origin: *

# The server never changed. Only your browser was fooled.

The server keeps sending exactly what it always sent. Only your local browser is fooled into accepting the response. Some variants go further and strip Content-Security-Policy or X-Frame-Options headers while they are at it.

The risks

Header rewriting on every site requires sweeping access. These extensions ask for the "read and change all your data on all websites" permission (the <all_urls> host permission) plus webRequest or declarativeNetRequest. While enabled, an extension with that access can observe every request and read page content on every website in every tab.

• Supply chain risk. Extensions rot, get abandoned, or change ownership, and a future update ships to your browser with the same broad permissions you already granted.
• The real bug stays hidden. The extension only changes what your own browser accepts. Every real user still hits the CORS error, so the server misconfiguration still has to be fixed before production.
• Credentialed sites break. Overwriting CORS headers on sites that already send correct ones corrupts them: a response fetched with credentials is rejected when Access-Control-Allow-Origin is the wildcard *, so sites that worked normally can fail while the extension is on.
• Security headers get stripped. Variants that remove Content-Security-Policy or X-Frame-Options lower the protection of every page you visit, not just the app under development.

If you must use one

Sometimes you need an answer in the next five minutes and an extension is the shortest path. Contain the blast radius:

• Install it in a dedicated Chrome profile used only for development, never in the profile where you read mail or stay signed into services.
• Keep the extension disabled except while actively debugging the cross-origin call.
• Never sign into any account inside that development profile.
• Remove the extension when the debug session is over instead of letting it linger.

Safer alternatives

Each option below fixes the request path itself instead of patching your browser, so the result survives code review, teammates, and production:

• Proxy through your dev server. The Vite dev server proxy forwards API calls server-side, so the browser only talks to its own origin. It is committed to the repo and works for everyone on the project.
• Fix the server when you own it. Return the correct Access-Control-Allow-Origin headers from your API; the only fix that also works for your users.
• Use a public proxy for third-party public APIs. When the API is not yours and sends no CORS headers, call it through a public CORS proxy that adds the headers for you. Public data only: the proxy operator can observe the traffic.

Good questions.