Web security - CORS

CORS itself is not a vulnerability — it is a browser security mechanism. The real risk arises from misconfiguration.

When CORS is improperly configured, it effectively dismantles the Same-Origin Policy and allows attackers to read sensitive cross-origin data.

Below is a structured, practitioner-level analysis of the real-world impact of CORS misconfigurations.

---

1. The Security Boundary CORS Is Meant to Protect

Browsers enforce the Same-Origin Policy (SOP):

JavaScript from A.com cannot read responses from B.com.

CORS allows a server to explicitly relax that restriction by sending headers such as:

• Access-Control-Allow-Origin
• Access-Control-Allow-Credentials
• Access-Control-Allow-Headers
• Access-Control-Allow-Methods

The core issue:

If the server mistakenly trusts an attacker-controlled Origin, the browser will legitimately hand sensitive response data to malicious JavaScript.

This is not theoretical — this is a controlled bypass of SOP.

---

2. Primary Security Impact

2.1 Account Data Exfiltration (Most Common and Most Severe)

Typical vulnerable configuration:

Access-Control-Allow-Origin: https://evil.com
Access-Control-Allow-Credentials: true

or worse:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Attack chain:

1. Victim is logged into bank.com
2. Victim visits evil.com
3. Malicious JavaScript executes:

fetch("https://bank.com/api/userinfo", {
  credentials: "include"
})

1. Browser automatically attaches session cookies
2. Server allows cross-origin access
3. JavaScript reads the JSON response
4. Data is exfiltrated

Potentially exposed data:

• Personally identifiable information (PII)
• Order history
• JWT tokens
• API keys
• Administrative metadata
• Internal service responses

Important distinction:

This is not CSRF.
CSRF allows blind requests.
CORS misconfiguration enables read access.

Severity: Critical.

---

2.2 Internal Network Data Exposure (Browser-Based SSRF)

If an internal interface:

• Is reachable from the victim’s browser
• Allows credentials
• Has permissive CORS

Then an attacker can do:

fetch("http://192.168.1.1/admin")

This may expose:

• Router configuration
• NAS storage interfaces
• Kubernetes dashboards
• Internal admin APIs

This is effectively a browser-assisted SSRF.

Severity: Critical in enterprise environments.

---

2.3 JWT / Token Theft

If a cross-origin-readable endpoint returns:

{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

An attacker gains:

• Full session replay capability
• Long-lived authentication tokens
• Potential privilege escalation

In modern SPA architectures, this is common and high-impact.

---

2.4 Administrative Panel Exposure

Example:

Access-Control-Allow-Origin: https://*.example.com

If subdomain registration is possible (e.g., user-controlled content, forgotten DNS entries), an attacker can host:

evil.example.com

Then read data from:

admin.example.com

This represents a collapse of trust boundaries across subdomains.

---

2.5 Amplification via XSS

If:

• A low-privilege subdomain has XSS
• The main domain trusts *.example.com via CORS

Then:

XSS → Cross-origin fetch → Sensitive data exfiltration

This converts a limited XSS into full data compromise.

---

3. Real Risk Evaluation Criteria

As a penetration tester, I do not report “CORS present” as a vulnerability by default.

I evaluate whether all of the following conditions are met:

Condition	Required for High Severity
Access-Control-Allow-Credentials: true	Yes
Attacker-controlled Origin allowed	Yes
Sensitive response data	Yes
Browser-exploitable context	Yes

Without these, many CORS findings are low-impact or informational.

---

4. Common Misconfiguration Patterns

4.1 Origin Reflection

Server blindly reflects:

Access-Control-Allow-Origin: <Origin header>

Without strict whitelist validation.

This is the most common real-world issue.

---

4.2 Weak Suffix Matching

Example:

if origin.endswith("example.com"):

Bypass:

evil-example.com

Improper domain validation leads to trust bypass.

---

4.3 Trusting null Origin

Access-Control-Allow-Origin: null

Attackers can generate null origins via:

• sandboxed iframes
• file:// protocol
• data URLs

This is often overlooked.

---

4.4 Wildcard with Credentials

This violates the CORS specification, yet some backend implementations incorrectly allow it.

If operational, it is critical.

---

5. Difference from CSRF

Aspect	CSRF	CORS Misconfiguration
Can read response?	No	Yes
Requires user interaction?	Often	Just visiting a page
Data exfiltration possible?	No	Yes
Typical severity	Medium	High to Critical

Organizations frequently misjudge this risk, assuming CSRF tokens mitigate it. They do not.

CORS affects read capability, not just request submission.

---

6. Real-World Bug Bounty Impact

Major cloud providers, fintech platforms, and SaaS vendors have paid significant bounties for exploitable CORS misconfigurations involving:

• Cross-account data access
• API key leakage
• Internal service exposure
• Admin panel data retrieval

Severity is highly context-dependent but often rated High or Critical when exploitable.

---

7. Remediation Guidance

1. Never use * with credentials.
2. Enforce strict, exact-match origin whitelists.
3. Do not implicitly trust subdomains.
4. Do not allow null unless absolutely required.
5. Apply CORS logic server-side with robust validation.
6. Avoid enabling CORS on sensitive endpoints by default.

---

8. Professional Assessment Mindset

When I encounter CORS during testing, I ask:

1. Are cookies included?
2. Is the response readable?
3. Is the data sensitive?
4. Is internal network access possible?
5. Are subdomains attacker-controllable?
6. Can this chain with XSS?

Only when these elements form a viable attack chain does the issue become high severity.