CORS
CORS is not a vibe setting
A wildcard origin can be harmless on a public asset endpoint and dangerous on an authenticated API. Know which one you actually shipped.
· 4 min read
CORS bugs usually start as development convenience. The frontend cannot call the API, the assistant suggests allowing every origin, the error disappears, and the setting survives into production. That is not a rare story. It is the common one.
The risk depends entirely on the endpoint
A public read-only asset endpoint with a wildcard origin is genuinely fine. An authenticated API that also accepts credentials is a different situation altogether, because any site your signed-in user visits can then read responses as them.
The problem is rarely the first decision. It is that the setting gets copied broadly because it fixed a browser error once, and nobody revisits which endpoints inherited it.
Reflecting the origin is worse than a wildcard
Browsers refuse to combine a wildcard with credentials, which quietly protects a lot of misconfigured sites. Reflecting whatever Origin was sent bypasses that protection while looking more specific and therefore safer.
If you see code that echoes the request origin back into the response header, treat it as the finding — particularly alongside Access-Control-Allow-Credentials: true.
Fixing it without breaking your app
Start by mapping who should legitimately call the API. If only your production app should, allow that origin. If multiple customer origins are valid, generate the allowlist deliberately rather than reflecting arbitrary input.
CORS is not a security boundary by itself — it does not authenticate anyone. But a bad policy removes a useful browser protection, and that is reason enough to make it explicit rather than inherited.
Common questions
Is Access-Control-Allow-Origin: * always bad?
No. On a genuinely public endpoint that returns nothing user-specific, it is the correct setting. It becomes dangerous when the same endpoint returns data that depends on who is asking.
Why is reflecting the Origin header dangerous?
It grants access to every origin while appearing restrictive, and unlike a wildcard it can be combined with credentials — which means another site can make authenticated requests as your logged-in user.
Does CORS protect my API?
No. CORS controls what browsers allow other websites to read. It does nothing about direct requests, so authentication and authorisation still have to be enforced server-side.
Keep reading
AI-generated auth needs server-side verification
If the server trusts a client session shape, a role string, or a hidden input, the app is not protected by the login screen it displays.
Why AI-built sites forget security headers
Generated code optimises for visible functionality. Security headers stay invisible until a scanner, a browser, or an attacker asks for them.
The security checklist for vibe-coded websites
A practical pre-launch pass for sites built quickly with AI: the checks that catch public mistakes without turning the project into a month-long audit.