How to Fix CORS Misconfiguration
Use this page when the CORS Checker shows overly broad origin policy, reflected origins, or risky credential behavior.
What This Means
CORS fixes should be based on the browser flows your application actually supports. The wrong fix is to swap one broad wildcard for another reflection rule. The right fix is to define trusted origins deliberately, narrow credentialed behavior, and retest the full browser flow including preflight requests.
| 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
Express CORS allowlist example
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
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.
- Review the endpoint again if it starts handling sensitive data later.
Is CORS a substitute for authentication?
No. It only affects what browsers can read cross-origin.
- Keep server-side auth in place.
- Treat CORS as an additional browser-facing policy.