CORS Misconfiguration

Turning off the browser's safety features out of frustration.

The idea

The Same-Origin Policy (SOP) is a critical browser security mechanism that prevents a malicious website (like `hacker.com`) from reading data from another website (like `bank.com`) using JavaScript. Cross-Origin Resource Sharing (CORS) is a feature that allows a server to explicitly relax this policy and allow specific domains to read its data.

A CORS misconfiguration happens when a developer gets frustrated by CORS errors during development and simply allows all domains to read the API data, effectively destroying the SOP protection.

How it works (Strict Origins)

Never configure a production API to reflect the `Origin` header blindly, and never use `*` alongside `Access-Control-Allow-Credentials: true` (most browsers block this anyway, but relying on browser quirks is bad practice). You must specify an explicit whitelist of allowed domains.

# VULNERABLE: The "I just want it to work" configuration
# Reflects ANY domain back to the user, allowing hacker.com to read data.
Access-Control-Allow-Origin: *
# Or even worse (Dynamic Reflection):
Origin = request.headers.get("Origin")
Access-Control-Allow-Origin: {Origin}

# SECURE: Strict Whitelisting
ALLOWED_ORIGINS = ["https://bank.com", "https://api.bank.com"]

Origin = request.headers.get("Origin")
if Origin in ALLOWED_ORIGINS:
    Access-Control-Allow-Origin: {Origin}
    Access-Control-Allow-Credentials: true

Watch out for

• Regex Mistakes: Checking `if Origin.startswith("https://bank.com")` allows an attacker to bypass the check by registering `https://bank.com.hacker.com`. Always match exact domains, or use very strict regex parsing for subdomains.
• Null Origin: Sometimes an attacker can force a request to have a `null` Origin (e.g., using a sandboxed iframe). If the server explicitly whitelists the string `"null"`, the attacker wins.
• Intranet Exposure: CORS is often disabled on internal company APIs (`192.168.x.x`) because they are "safe behind the firewall." However, an attacker can trick a developer's browser into querying that internal API. If CORS allows `*`, the attacker's script running on the developer's machine can steal the internal data and send it out.

Worked example

A crypto exchange API at `api.crypto.com` is configured with `Access-Control-Allow-Origin: *`. A user logs into the exchange, then browses a seemingly innocent cryptocurrency forum (`crypto-chat.com`). The forum contains hidden JavaScript that executes `fetch('https://api.crypto.com/wallet/private-key')`. Because the exchange returns the wildcard `*` CORS header, the victim's browser allows the forum's JavaScript to read the response. The attacker steals the private key and drains the wallet.

Check yourself

Why does a CORS wildcard (`*`) not automatically protect against CSRF attacks?