CORS Misconfiguration

The Same-Origin Policy stops one site reading another site’s authenticated responses. CORS is how a server deliberately relaxes that — and a sloppy CORS policy hands the key to any site the victim visits. The dangerous combination is always the same: Access-Control-Allow-Credentials: true together with an Access-Control-Allow-Origin the attacker can get named.

What is the vulnerability?

• Reflected origin. The server echoes whatever Origin it receives into Access-Control-Allow-Origin, with credentials, so every origin — including the attacker’s — is allowed.
• Null origin. The server adds null to the allowed set. But null is exactly what a sandboxed iframe or a data: page sends, so the attacker produces it at will.
• Suffix match. The server allows any host ending in ravens.lab, so evil-ravens.lab — a domain the attacker registers — passes.

Why does it happen?

“Allow credentials” cannot be combined with the wildcard *, so developers reach for a dynamic value instead: reflect the origin, or match it loosely. Each shortcut turns the allowlist into “anyone”.

How do you stop it?

Keep a fixed allowlist of exact, trusted origins and match them with ===. Never reflect the request origin, never allow null, and never use a suffix or substring test. If a response needs no credentials, do not set Allow-Credentials at all.

The three labs below walk this: read the response from a reflected origin, from null, and from a suffix-match bypass.