Add CORS response headers in one tab

Your page, for example on http://localhost:3000, calls an API on another domain, and the browser blocks the response because it lacks CORS headers. While you test, you want to add those headers in one tab only, without changing the server.

Steps

1. Install Wirelet, then open your page in a tab, for example http://localhost:3000.
2. Open Wirelet: click its icon in the toolbar, or press Alt+Shift+Y (Control+Shift+Y on a Mac). Choose “New profile”.
3. Under “Sites”, choose “Only these sites” and add the API’s host, for example api.example.com.
4. Choose “New header”. In “Applies to”, choose “Response”, keep “Set”, and type the name Access-Control-Allow-Origin with your page’s origin as the value: http://localhost:3000.
5. If your requests send an Authorization header or headers of their own, add a response header Access-Control-Allow-Headers that names them, for example Authorization, Content-Type. For methods such as PUT or DELETE, add Access-Control-Allow-Methods. If they send cookies, add Access-Control-Allow-Credentials with the value true.
6. Tick “This tab only”.
7. Choose “Done”, then switch the profile on while this tab is the active one. Your browser asks for access to the API’s site: allow it.
8. Your page’s site needs access too. Opening Wirelet from this tab gives it for as long as the tab stays on that site; to keep it, choose “Allow this site” when Wirelet offers it.
9. Reload the tab.

With cookies, Access-Control-Allow-Origin must be your page’s exact origin: the browser refuses *.

What this cannot fix

A preflight the server refuses

Before some requests, one with an Authorization header for example, the browser sends an OPTIONS request. If the server answers it with an error status, such as 401, 404 or 405, the request fails whatever the headers say: Wirelet changes headers, not status codes. In our tests in Chromium 141 and 153, a preflight answered 204 went through once the headers were added; one answered 405 did not.

Access-Control-Allow-Headers: * and Authorization

The Fetch standard leaves Authorization out of the wildcard. Chrome and Edge still accept it for now, but the developer tools report it as deprecated (Issues panel), and other browsers refuse it: name Authorization in the list.

Site access

Your browser applies the headers to a page’s request only if Wirelet has access to both the API’s site and the page’s site. When one is missing, the profile shows “Blocked”, or nothing changes.

Cached responses

A response that a page’s service worker serves from its cache never reaches the network, so no header can change: reload while bypassing the cache.

Only your browser

The server and everyone else still get its own CORS answer: configure the server before you ship.