CORS misconfiguration: the door you leave open to every site

The principle

By default, a browser stops site A from reading site B’s responses on its own behalf — the same-origin rule. CORS (Cross-Origin Resource Sharing) is the mechanism that lets a site explicitly allow certain other sites to read its responses anyway.

The problem appears when that permission is granted far too broadly, or thought through poorly, instead of being limited to a precise list of trusted partners.

A concrete example

An API systematically responds by reflecting back whatever origin made the request, combined with permission to send credentials (cookies) along with it. Any malicious site can then lure a victim onto it, trigger a request to your API WITH the victim’s already-valid session cookies, and READ the response that comes back.

The result: theft of personal data, invoices, access tokens — entirely invisible to the victim, who clicked nothing explicit beyond visiting a trap page.

Why it’s serious

A misconfigured CORS policy turns every logged-in visitor of your site into a potential victim the moment they visit any malicious site elsewhere on the web — no specific click required once they’re there.

Equally dangerous variants exist: accepting the special “null” origin (reachable via a sandboxed iframe), or validating with “starts with”/“contains” instead of strict equality, which lets an attacker register a look-alike trap domain.

How to protect yourself

Never blindly reflect the received origin back in the response. Compare the origin against an exact allowlist, using strict equality — never a poorly escaped regular expression where an unprotected dot ends up matching any character.

Never combine the “*” wildcard with permission to send credentials: the specification explicitly forbids it, yet some configurations still let the combination slip through by mistake. If the API has no structural need to be called from another domain, don’t enable CORS at all.

How SauronSec detects it

A series of controlled origins is sent (a completely foreign domain, the “null” origin, prefix and suffix variants) with exact verification: does the server echo back that precise origin as authorized? Every positive reflection is confirmed a second time before being reported.

Whether credential-sharing is permitted determines the severity actually reported: a reflection with no cookies attached doesn’t carry the same real-world impact as one that exposes fully authenticated data.