Access-Control-Allow-Origin: * — the risk and the fix

Setting Access-Control-Allow-Origin to * tells browsers that any website may make cross-origin requests to your API. For a truly public, unauthenticated endpoint that is fine. For anything that relies on the browser sending cookies or that returns data tied to a user, a wildcard origin combined with credentials is a real exposure, and browsers will even block the dangerous combination for you.

Why it's a problem

If your API authenticates with cookies and you reflect a permissive origin while allowing credentials, a malicious page the victim visits can make authenticated requests to your API and read the responses using the victim's session. The wildcard is safe only when the endpoint is genuinely public and carries no per-user data or credentials.

// allows every site on the internet to call this API
app.use(cors({ origin: "*", credentials: true }));   // browsers block this combo

const allowed = new Set([
  "https://app.example.com",
  "https://admin.example.com",
]);

app.use(cors({
  origin: (origin, cb) => cb(null, !origin || allowed.has(origin)),
  credentials: true,
}));

Why AI tools write this

When an assistant is asked to 'fix the CORS error,' the wildcard is the change that makes the error disappear immediately, so it is the one that gets written. It resolves the symptom the developer reported without reasoning about which origins should actually be trusted, because that is a judgment call about the app, not the error.

The quick fix

• Replace the wildcard with an explicit allowlist of the origins you control.
• Never combine origin: '*' with credentials: true.
• Only leave a wildcard on endpoints that are fully public and return no user-specific data.