CORS Misconfigurations That Silently Expose Your API to Any Origin

You set up CORS headers so your frontend can talk to your API, tested that requests work, and moved on. That's exactly how most CORS misconfigurations slip into production — they look correct until an attacker reads your users' private data from a page they control.

CORS mistakes are different from most vulnerabilities: they don't generate errors in your logs, they don't crash anything, and they often pass code review because the intent seems reasonable. Understanding the precise patterns that create exposure is the only way to catch them.

What CORS Is Actually Doing (and What It Is Not)

Browsers enforce the Same-Origin Policy (SOP): a script running on https://evil.com cannot read the response to a fetch request sent to https://yourapi.com. CORS is a controlled relaxation of that rule. When your server sends Access-Control-Allow-Origin: https://yourfrontend.com, it tells the browser that one specific origin is allowed to read the response.

Two things are critical to understand before we go further:

• CORS controls whether a browser script can read a response. It does not prevent the request from being sent. Your server still processes the request; CORS only gatekeeps the client's ability to see the result.
• CORS headers are enforced by the browser. A server-side script, curl, or Postman ignores them entirely. If your API relies on CORS as its only protection, any non-browser client bypasses it completely.

What You'll Learn

• Why wildcard origins combined with credentials are dangerous even when browsers block them by default
• How reflecting the request's Origin header without validation hands attackers carte blanche
• The null origin loophole and why it's exploitable from sandboxed iframes
• How loose regex patterns let attackers register look-alike domains
• Concrete header configurations that fix each class of problem

The Wildcard + Credentials Combination

The most well-known CORS rule is that you cannot combine Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true. Browsers will block the response if you try. So teams that need credentialed cross-origin requests (cookies, HTTP auth) switch to reflecting the origin dynamically — and that is where things go wrong.

But even a plain wildcard without credentials creates real risk for APIs that rely on network-level access control. If your API is internal and expects only intranet clients, a wildcard CORS policy lets a malicious external page trigger requests from an internal user's browser and read the responses.

# Dangerous: wildcard on an internal-facing API
Access-Control-Allow-Origin: *

# Safe for truly public, read-only, unauthenticated data only
Access-Control-Allow-Origin: *

Wildcard is only safe when the data is genuinely public, requires no authentication, and carries no user-specific content. If any of those conditions are false, use an explicit allowlist.

Reflecting the Request Origin Without Validation

This is the most dangerous pattern in the wild. Some servers are configured to take whatever value appears in the incoming Origin header and echo it back as Access-Control-Allow-Origin. The intent is usually