Fix CORS Errors in Local Development Without Backend Changes — HeaderSnap ModHeader was removed from Chrome & Edge over a hidden data collector — what happened and what to do
HeaderSnap
← All posts
March 17, 2026

How to Fix CORS in Local Development Without Touching Your Backend

You’re building a frontend. The API you’re calling doesn’t have CORS set up yet — or it’s set up for production but not localhost. Every request fails with:

Access to fetch at 'https://api.example.com/data' from origin 'http://localhost:3000'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present
on the requested resource.

The backend fix is straightforward — add the right response headers. But if you don’t control the backend, or the backend team is busy, or you’re working against a third-party API during development — you’re stuck waiting.

You don’t have to be. Here’s how to inject CORS headers locally in three steps, without touching any backend configuration.

Why CORS Errors Happen (The Short Version)

CORS (Cross-Origin Resource Sharing) is a browser security policy. When your frontend at http://localhost:3000 makes a request to https://api.example.com, the browser checks the response for an Access-Control-Allow-Origin header. If it’s missing or doesn’t match your origin, the browser blocks the response — even if the server returned a 200 OK.

The server doesn’t block the request. The browser blocks the response. That distinction matters: if you can control what headers the browser sees on the response, you can unblock yourself locally without waiting for a backend change.

That’s exactly what HeaderSnap makes possible.

The Fix: Inject CORS Headers on the Response

HeaderSnap is a Chrome extension that lets you add, modify, and remove HTTP request and response headers — scoped to specific URL patterns. You can inject Access-Control-Allow-Origin (and other required CORS headers) onto API responses, locally, so the browser stops blocking them.

This works for your local development session. It doesn’t affect anyone else, it doesn’t modify the actual API, and it doesn’t require touching the backend.

Step 1 — Install HeaderSnap

Get HeaderSnap at headersnap.com. No account required.

Step 2 — Create a response header rule

Open the HeaderSnap popup from the Chrome toolbar.

  1. Click Add Rule

  2. Set the URL Pattern to match your API endpoint. For example:

    • https://api.example.com/* — applies to all endpoints on that domain
    • https://api.example.com/v2/users* — applies to a specific path

  3. Set the Header Target to Response (not Request)

  4. Set the header name and value, then click Add to create the rule

Each rule handles exactly one header. Create three separate rules — one for each CORS header you need:

  • Rule 1: Access-Control-Allow-Origin → * (or http://localhost:3000 if using credentials)
  • Rule 2: Access-Control-Allow-Methods → GET, POST, PUT, DELETE, OPTIONS
  • Rule 3: Access-Control-Allow-Headers → Content-Type, Authorization

For each rule, click + Add Rule, set the URL pattern and response target, fill in the header name and value, and click Add.

Step 3 — Test the request

Make your request from the frontend. The browser will now see the injected Access-Control-Allow-Origin header on the response and allow it through.

If you’re using credentials (cookies, auth tokens), use your specific origin instead of * — Access-Control-Allow-Origin: http://localhost:3000 — and add Access-Control-Allow-Credentials: true.

Handling Preflight Requests

For non-simple requests (anything with a custom header like Authorization, or methods like PUT or DELETE), the browser first sends a preflight OPTIONS request. The API must respond to that OPTIONS request with the right CORS headers — or the actual request never goes out.

HeaderSnap’s URL pattern rules apply to all HTTP methods, including OPTIONS preflight requests. If your existing rule already covers the API endpoint, no additional rule is needed — the CORS headers are injected on the preflight response automatically. If preflight requests go to a different URL path than your main requests, create a second rule scoped specifically to that path.

The URL pattern tester in HeaderSnap lets you validate that your pattern actually matches the preflight URL before you rely on it.

Scoping Your Rules Correctly

One thing worth being careful about: don’t set Access-Control-Allow-Origin: * with an overly broad URL pattern like *://*/*. That would apply to every site you visit, which can break things elsewhere.

Scope your rules specifically:

  • Use https://api.example.com/* rather than *
  • Or even more specific: https://api.example.com/v2/*

HeaderSnap supports both glob patterns and regex, so you can be as precise as needed.

Using Profiles to Keep Dev Rules Separate

If you work across multiple environments — local dev, staging, production — HeaderSnap’s profile system lets you keep your development-only CORS rules in a dedicated profile that you can activate and deactivate without touching your other configurations.

Create a “Local Dev” profile, add your CORS injection rules there, and switch it off when you’re done. Your other header rules stay untouched.

When to Stop Using This Fix

This is a local development workaround — not a production solution. Once you hand off to the backend team or deploy to an environment where the server is configured correctly, you should turn off your CORS injection rule and verify the real headers are working.

The rule of thumb: if your CORS rules are still active in your browser when you’re testing against staging or production, something is off. Use HeaderSnap’s profile system to make it easy to switch between your development-mode configuration and a clean state.

Stuck with a CORS error? Three steps, no backend required.

👉 Install HeaderSnap free →