Fix CORS Misconfiguration | Step-by-Step Guide
If your browser console shows 'Access to fetch at [URL] from origin [origin] has been blocked by CORS policy,' the fix is always server-side — not a browser setting or a plugin. CORS misconfigurations come in three forms that require different remediation: a wildcard origin (*) applied to authenticated endpoints, a reflected-origin pattern that echoes back any Origin value the browser sends, and credentialed CORS that lets arbitrary domains read your authenticated API responses. This guide shows how to diagnose which pattern you have, replace it with an explicit allowlist in Express, Nginx, or Apache, and verify the fix with real preflight requests — not just curl.
What This Means
CORS (Cross-Origin Resource Sharing) is the browser mechanism that controls whether JavaScript on one origin can read responses from a different origin. When the server does not send a matching Access-Control-Allow-Origin header, the browser blocks the response and logs: 'Access to fetch at [URL] has been blocked by CORS policy: No Access-Control-Allow-Origin header is present.' The three most dangerous CORS misconfigurations are: (1) Wildcard origin — Access-Control-Allow-Origin: * on an endpoint that handles authentication or session cookies. The spec forbids credentials with wildcard, but some frameworks silently fall back to reflection; (2) Reflected origin — the server reads the Origin request header and echoes it back unchanged, trusting every domain the requester controls including attacker-owned sites; (3) Credentialed wildcard — Access-Control-Allow-Credentials: true combined with an overly permissive origin policy, allowing any browser origin to read your authenticated API responses. The correct fix for every pattern is to replace the broad policy with an explicit allowlist of origins your real browser flows require, restrict credentials to the endpoints that need them, and retest both preflight (OPTIONS) and credentialed requests after the change.
| Pattern | What to verify | Why it matters |
|---|---|---|
| Wildcard origin | Whether the endpoint is truly public and anonymous | This is unsafe for sensitive authenticated APIs. |
| Reflected origin | Whether the server validates a real allowlist | Reflection can trust origins that were never intended. |
| Credentials | Whether cookies or auth headers are required cross-origin | Credentialed CORS needs much tighter policy. |
| Preflight handling | Allowed methods and headers | OPTIONS behavior should match the real contract. |
Common Causes
Patterns worth checking first
- Debug-first config: A permissive policy survived after development or integration testing.
- Reflected allowlist logic: The server trusted incoming Origin values too loosely.
- Mixed ownership: Frontend and backend teams each assumed the other side had already constrained the policy.
How To Confirm It Safely
Confirmation steps
- Identify which endpoints truly need cross-origin browser access.
- Confirm whether credentials are required for the affected flow.
- Inspect real preflight requests and response headers in the browser.
- Document the smallest set of trusted origins before changing config.
Fix Workflow
- Classify the endpoint. Decide whether it is public anonymous content or a sensitive authenticated API.
- Replace broad policy with an allowlist. Define the exact origins that should be trusted instead of relying on reflection or wildcards.
- Review credential use. Keep cross-origin credentials only where the browser flow genuinely requires them.
- Retest real browser traffic. Validate preflight and credentialed requests after policy changes.
Implementation Examples
const allowedOrigins = ['https://app.example.com'];
app.use(cors({
origin(origin, callback) {
if (!origin || allowedOrigins.includes(origin)) {
return callback(null, true);
}
return callback(new Error('Origin not allowed'));
},
credentials: true
}));Rollout Risks
A narrow allowlist can still break production if environment hosts differ
Staging, admin, or alternate application origins are often forgotten.
- Inventory legitimate origin hosts first.
- Retest production and non-production browser entry points.
Credential cleanup can break sessions if the frontend depends on cookies
Cross-origin auth behavior should be mapped before you remove it.
- Confirm session design and login flow.
- Retest browser requests, not just API responses in isolation.
Validation Checklist
Post-fix validation
- Sensitive endpoints no longer trust wildcard or arbitrary reflected origins.
- Credentialed behavior exists only where the real flow needs it.
- Preflight responses now match the intended method and header policy.
- The CORS Checker confirms safer origin handling.
FAQ
How do I fix 'Access to fetch has been blocked by CORS policy'?
This browser error means the server did not send an Access-Control-Allow-Origin header that matches the requesting origin. The fix is on the server side, not the browser.
- Identify the exact origin (scheme + domain + port) that needs access and add it to a server-side allowlist.
- Do not respond with Access-Control-Allow-Origin: * on endpoints that use cookies, Authorization headers, or session tokens.
- For preflight failures, also verify that the OPTIONS method is handled and that Access-Control-Allow-Methods and Access-Control-Allow-Headers match the real request.
- After the server-side fix, retest with a real browser request — the CORS Checker surfaces the actual headers your server sends.
What is a CORS misconfiguration and why is it a security risk?
A CORS misconfiguration means the server's cross-origin policy is broader than the application's trust model requires. The most dangerous patterns are wildcard origin on credentialed endpoints, and reflected-origin logic that echoes any incoming Origin value back as trusted.
- Wildcard (Access-Control-Allow-Origin: *) with Access-Control-Allow-Credentials: true is invalid per the spec, but some frameworks accept it silently or fall back to reflection.
- Reflected-origin patterns trust whatever origin the browser sends — an attacker can craft a page on a malicious domain that reads authenticated API responses.
- CORS misconfigurations are OWASP-classified vulnerabilities and appear in many real-world data breach reports.
- The CORS Checker tests for wildcard origin, reflection behavior, and credential exposure from the same public edge your users reach.
How do I fix a CORS error in Express (Node.js)?
The most common Express CORS mistake is using cors({ origin: '*', credentials: true }). Use an explicit allowlist instead.
- Install the cors package and pass an origin function that checks against an allowlist array rather than a wildcard string.
- Set credentials: true only on endpoints that genuinely need cross-origin cookie or Authorization header access.
- Use the code example on this page as a starting point — it shows an allowlist function with a rejected-origin error callback.
- Restart the server and retest real browser requests, not just curl, after the change.
How do I fix a CORS error in Nginx?
CORS in Nginx is configured via add_header directives in the server or location block. The common mistake is adding headers unconditionally without checking the Origin.
- Use `if ($http_origin ~ '^https://(app\.example\.com)$')` to restrict which origins receive the header.
- Add the OPTIONS preflight handler separately: `if ($request_method = 'OPTIONS') { return 204; }`.
- Avoid using add_header Access-Control-Allow-Origin '*' at a global level — it applies to every response including sensitive endpoints.
- After the Nginx change, reload the config (`nginx -s reload`) and retest with the CORS Checker.
What is a preflight request and why is it failing?
Browsers send a preflight OPTIONS request before the real request when the method is PUT, DELETE, or PATCH, or when custom headers like Authorization or Content-Type: application/json are present.
- The server must respond to OPTIONS with the correct Access-Control-Allow-Methods and Access-Control-Allow-Headers headers.
- A preflight failure often means the OPTIONS route is not handled at all — add an explicit OPTIONS route or framework middleware that responds with 204.
- Access-Control-Max-Age can cache the preflight result to reduce round-trips in production.
- The browser will not send the actual request if the preflight fails — test the OPTIONS response directly using curl or the CORS Checker.
Can I use wildcard origin on public APIs?
Yes, but only where the resource is truly anonymous and low risk.
- Keep credentials out of that design — Access-Control-Allow-Credentials: true combined with wildcard origin is a misconfiguration.
- Review the endpoint again if it starts handling authentication, sessions, or sensitive data.
- Public static assets (fonts, images, public JSON) are safe to serve with wildcard origin.
Is CORS a substitute for authentication?
No. CORS is a browser-enforced policy — it only controls what browser clients can read cross-origin. It does not protect server-side data from direct API access.
- A server-side API with no authentication is fully readable by any non-browser client (curl, Postman, server-to-server requests) regardless of CORS policy.
- Keep server-side authentication and authorization in place. Treat CORS as an additional browser-facing control layer, not a replacement for auth.
- CORS misconfiguration is serious because it breaks the browser-level control, but fixing CORS alone does not make an unprotected endpoint safe.
How do I fix CORS errors in local development?
In development, CORS errors are common when a frontend on localhost:3000 calls a backend on localhost:8080. This is a different origin by port.
- Add localhost:3000 (or whatever port your dev server uses) to the server-side allowlist for development environments only.
- Never deploy a development allowlist to production — use environment-specific config or environment variables to separate dev and prod origins.
- A browser extension that disables CORS will silence the error locally but does not fix the production problem — always fix it server-side.
How do I test whether my CORS fix worked?
Always test from a real browser context after making CORS changes — testing with curl or Postman skips the browser same-origin enforcement.
- Run the Vulnify CORS Checker against the live endpoint — it sends real cross-origin browser-style requests and reports what headers the server returns.
- Check the browser console Network tab and look for the Access-Control-Allow-Origin header in the preflight and actual response.
- Test credentialed flows separately — a non-credentialed test passing does not confirm that credentialed requests also work correctly.