CORS: When Your API Doesn't Know Who It's For

Most teams treat CORS like a browser annoyance. It's not. CORS won't stop attackers. It won't magically "secure" your API. What it does control is something much more practical: who can call your API from a browser context.

And here's the uncomfortable question: Is your API private or public? Because if you don't know the answer, your CORS configuration is probably wrong.

I've seen both extremes:

• Access-Control-Allow-Origin: * copy-pasted into production "to make things work"
• Overly strict origin rules on APIs that are meant to be integrated everywhere

Neither is universally right. Both can be wrong.

Open CORS is not automatically bad. Open CORS with cookies and implicit authentication? That's where things get dangerous. Restricted CORS on a private web app backend? Good. Restricted CORS on a product API meant for integrations? Friction.

The real problem isn't configuration. The real problem is that teams never consciously decide: Is this API internal or external?

That's why Rentgen flags CORS as Info, not Fail. Not to judge. But to force the architectural question early — before security reviews, broken integrations, or production surprises do it for you.

If you want the full breakdown (OWASP angle, private vs public API rules, and when open CORS is actually fine), read the complete article.

👉 Full story: https://rentgen.io/api-stories/cors-policy-check.html