HTTPS & cookies

How to fix: CORS configuration

CORS (Cross-Origin Resource Sharing) headers decide which other websites' JavaScript may read responses from your server.

Why it matters

A public API that returns the same data to everyone is normally fine with Access-Control-Allow-Origin: *. It becomes a risk when responses depend on the logged-in user and the server allows arbitrary origins together with credentials, or blindly reflects whatever Origin it receives.

How to check

Send a request with an Origin header from a site you don't own and look at the Access-Control-Allow-Origin and Access-Control-Allow-Credentials response headers. Our CORS checker does this safely.

How to fix it

const allowed = new Set(['https://app.example.com', 'https://www.example.com']);
app.use((req, res, next) => {
  const origin = req.headers.origin;
  if (origin && allowed.has(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Vary', 'Origin');
  }
  next();
});

Common mistakes

• Reflecting the request's Origin without checking it against an allowlist, especially with Access-Control-Allow-Credentials: true.
• Forgetting the Vary: Origin header when the value changes per request, which can cause caches to serve the wrong one.
• Treating a wildcard on its own as automatically exploitable: browsers don't send cookies to a wildcard response, so it matters mainly when the data is sensitive or private-network.

Frequently asked questions

Related guides

• Cookie security flags (Secure, HttpOnly, SameSite)
• Content-Security-Policy header

Guidance is general. Test header and DNS changes on a staging copy first, and check your hosting provider's documentation for platform-specific steps.