You are building your app, the browser throws a red CORS error, you search a forum and copy the fix that promises everything will just work. It is usually the worst possible one. Let us understand what CORS is and why that shortcut is dangerous.
What CORS really is
By default, the browser does not let site-a.com read the response of an API on site-b.com. That is the same-origin policy, and it protects your users: it stops a malicious tab from reading data from another tab where you are logged in. CORS is the mechanism your server uses to say these specific origins are allowed, through the Access-Control-Allow-Origin header.
The mistake that breaks everything
The dangerous pattern is reflecting back whatever origin arrives and, on top of that, allowing credentials:
Access-Control-Allow-Originset to the requesting origin (dynamic reflection)- together with
Access-Control-Allow-Credentials: true
With that combination, any website your user visits can call your API using the user's session cookies and read the response. In other words, any random site can pull your user's private data without them noticing. The wildcard * is less severe because the browser forbids combining it with credentials, but it still does not belong in production.
How to configure it properly
Think defense, not convenience:
- Keep an allowlist of permitted origins and match it exactly. Never reflect what arrives without validating.
- Enable
Allow-Credentialsonly if you truly need to send cookies, and only for specific origins. - Limit methods and headers to what you use (
Allow-Methods,Allow-Headers). - Be careful about including
nullor third-party subdomains in the list.
Why it is hard to spot
This flaw is silent: everything works, there is no visible error and the app looks healthy. You only notice when someone abuses it. That is why you should review your CORS configuration explicitly on every deploy, instead of trusting that no error means it is fine.
Review your CORS with Scanaris
Scanaris runs a read-only check of whether your API reflects origins and how it responds to CORS headers, without launching attacks or touching your data: it only observes the public response. If it finds a dangerous setup, it gives you a fix prompt so your AI can rewrite it with an allowlist. Scan your site and avoid the flaw nobody sees until it is too late.