Cross-Origin Resource Sharing (CORS): The Deep Dive

Cross-Origin Resource Sharing (CORS) is a browser mechanism that relaxes the Same-Origin Policy (SOP). While intended to allow safe data sharing, misconfigurations can allow attackers to bypass SOP entirely and steal sensitive user data like API keys, session tokens, and personal information.

🔸 1. The Core Mechanics

To understand the attacks, you must understand the “Handshake.”

The Request (Browser)

When a browser makes a cross-origin request (e.g., from evil.com to bank.com), it automatically adds the Origin header.

GET /api/data HTTP/1.1
Host: bank.com
Origin: [https://evil.com](https://evil.com)
Cookie: session=...

The Response (Server)

The server decides whether to allow the request using three key headers:

1. Access-Control-Allow-Origin (ACAO): The specific domain allowed to read the response.

2. Access-Control-Allow-Credentials (ACAC): Must be true to allow the browser to share cookies/auth headers.

3. Access-Control-Allow-Methods: Allowed HTTP methods (GET, POST, etc.).

The Trap: If ACAC is true, the ACAO header cannot be a wildcard (*). It must match the requesting origin exactly. This forces developers to dynamically generate the ACAO header, leading to vulnerabilities.

🧨 2. Vulnerability Class 1: The “Reflection” Flaws

These occur when the server blindly trusts the client’s input to generate the ACAO header.

A. Basic Origin Reflection

The application reads the Origin header from the request and echoes it back in the Access-Control-Allow-Origin header.

Attack: The attacker hosts a script on evil.com.

Result: The server sees Origin: https://evil.com and responds with Access-Control-Allow-Origin: https://evil.com and Credentials: true. The browser allows the attacker to read the victim’s data.

B. Errors Parsing Origin Headers (Weak Regex)

Developers try to validate the origin but use flawed regular expressions.

Prefix Match: Allows normal-website.com.evil.com.

Suffix Match: Allows hackersnormal-website.com.

Protocol Blindness: Allows http://normal-website.com even if the site is HTTPS (see “Breaking TLS” below).

🧨 3. Vulnerability Class 2: The null Origin

The value null is a special origin sent by the browser in specific scenarios. Developers often whitelist it for local testing, not realizing it can be triggered by attackers.

The Attack Vectors

If a server whitelists Access-Control-Allow-Origin: null, it can be exploited in three ways:

1. Sandboxed Iframes:

   An attacker uses <iframe sandbox="allow-scripts ...">. Requests from this iframe are sent with Origin: null.

2. Local Files (file://):

   If an attacker can trick a victim into downloading and opening a malicious HTML file locally, requests from that file send Origin: null.

3. Cross-Origin Redirects:

   The attacker forces a redirect chain: evil.com -> vulnerable.com. In some redirect scenarios, the final request may have Origin: null. If whitelisted, the attacker captures the data.

🧨 4. Vulnerability Class 3: Trust Relationships & XSS

Even if CORS is configured “correctly” (only whitelisting specific trusted domains), the system is only as secure as its weakest trust.

The Scenario:

secure-bank.com allows CORS from partner-site.com.

partner-site.com has a Cross-Site Scripting (XSS) vulnerability.

The Attack:

1. The attacker injects a malicious script into partner-site.com (via the XSS).

2. The script makes a request to secure-bank.com.

3. The browser sends Origin: https://partner-site.com.

4. secure-bank.com trusts this origin and returns the sensitive data.

5. The attacker’s script exfiltrates the data.

Impact: XSS on a trusted partner domain equals full compromise of the main domain via CORS.

🧨 5. Vulnerability Class 4: Breaking TLS (The MITM)

This attack exploits the fact that some HTTPS sites allow CORS requests from their own insecure HTTP subdomains.

The Scenario:

https://secure.com trusts http://trusted.secure.com.

The Attack:

1. The attacker performs a Man-in-the-Middle (MITM) attack on the victim (e.g., public WiFi).

2. They intercept traffic to the insecure http://trusted.secure.com and inject malicious JS.

3. This script makes a CORS request to https://secure.com.

4. Since secure.com trusts the HTTP origin, it releases the data.

5. Result: The attacker bypasses TLS protections entirely by leveraging the insecure trust relationship.

🧨 6. Vulnerability Class 5: Intranet Exploitation

Most internal networks (Intranets) are less hardened than public sites. They often rely on IP-based authentication or allow Access-Control-Allow-Origin: *.

The Attack:

1. Attacker convinces a victim (employee) to visit evil.com.

2. evil.com uses the victim’s browser to scan the internal network (192.168.x.x).

3. If an internal app allows ACAO: * (common in dev environments), the attacker’s script can read internal documents and exfiltrate them to the public internet.

Note: This works even without credentials if the internal app relies solely on “being on the network” for access.

🛡️ 7. Prevention Strategies

1. Strict Whitelisting: Never reflect the Origin header. Check it against a hardcoded list of trusted domains.

2. Block null: Never whitelist the null origin.

3. Protocol Parity: Only allow HTTPS origins for HTTPS sites. Never trust HTTP.

4. Vary Header: Always send Vary: Origin. This tells proxies/caches that the response content (headers) changes based on the Origin, preventing cache poisoning.

5. Avoid Wildcards: Do not use * for internal resources or any resource handling credentials.

❓ 8. Interview Corner: 10 Advanced Questions

Q1: Can you exploit CORS if the server reflects the Origin but sets Access-Control-Allow-Credentials: false?

Answer:

Only if the data is accessible without authentication.

If the endpoint requires a session cookie, and ACAC is false, the browser will not send the cookie. The server will see an unauthenticated request and likely return an error or public data.

Exception: If the app uses IP-based auth (Intranet) and the victim is on the allowed network, the attack still works.

Q2: What is the “Null Origin” vulnerability and how is it exploited?

Answer:

It occurs when a server whitelists the string null in the ACAO header. It is exploited by using a sandboxed iframe (<iframe sandbox="allow-scripts ...">). Browsers send Origin: null for requests from such frames, matching the whitelist and allowing data theft.

Q3: How does XSS affect CORS security?

Answer:

If a Trusted Origin (Domain A) has an XSS vulnerability, it compromises Domain B (the target) if Domain B whitelists Domain A for CORS. The attacker uses the XSS on Domain A to launch authenticated CORS requests to Domain B, which are permitted because the Origin is trusted.

Q4: Explain the “Breaking TLS” CORS attack.

Answer:

It happens when a secure HTTPS site trusts an insecure HTTP subdomain for CORS. An attacker with network positioning (MITM) injects code into the HTTP traffic. This code sends requests to the HTTPS site. Since the HTTPS site trusts the HTTP origin, it returns sensitive data, which the attacker steals, effectively bypassing encryption.

Q5: Why is Access-Control-Allow-Origin: * dangerous on an Intranet?

Answer:

Internal apps often lack strong auth, relying on network perimeter security. If an internal app allows , an external attacker can use a victim employee’s browser as a proxy. The victim visits the attacker’s site, which JS-scans the internal network and reads the data because the internal server explicitly permits “everyone” () to read it.

Q6: Can you bypass a regex that validates *.normal-website.com?

Answer:

Yes. If the regex isn’t anchored correctly (^ and $), I can register hackersnormal-website.com (suffix match) or normal-website.com.evil.com (prefix/subdomain match). The server sees the trusted string inside the malicious domain and allows it.

Q7: What is the Preflight Request and when does it happen?

Answer:

A Preflight is an OPTIONS request sent by the browser before the actual request. It happens for “complex” requests—those using methods other than GET/POST/HEAD, or custom headers (like Content-Type: application/json). It asks the server permission to send the actual request.

Q8: What does Vary: Origin do?

Answer:

It instructs caches (CDNs/Browsers) to key the cache based on the Origin header. This prevents a “poisoned” cache scenario where a response containing ACAO: malicious.com (generated for an attacker) is served to a legitimate user, or vice versa.

Q9: Can CORS be exploited without user interaction?

Answer:

Usually, no. The victim must visit the attacker’s site (or a compromised site) while logged in to the target application. It is a client-side attack dependent on the victim’s browser context.

Q10: Is it safe to dynamically reflect the Origin if I validate it first?

Answer:

Yes, this is the standard secure implementation. You read the Origin, check if it exists in your database of trusted domains (exact match), and only then reflect it. If it doesn’t match, you return no CORS headers or a default error.

🎭 9. Scenario-Based Questions

🎭 Scenario 1: The “Null” Whitelist

Context: You see Access-Control-Allow-Origin: null in a response. The developer says it’s needed for their local file testing.

The Question: How do you prove this is a critical vulnerability?

The “Hired” Answer:

“I will build a Proof of Concept using a sandboxed iframe.

1. I create exploit.html with <iframe sandbox='allow-scripts allow-forms' srcdoc='...malicious JS...'>.

2. The JS inside attempts to read the endpoint.

3. The browser sends Origin: null.

4. The server accepts it and returns the data.

   This proves that anyone can bypass their SOP protections, not just their local files.”

🎭 Scenario 2: The Trust Chain

Context: api.target.com is secure. It only allows CORS from help.target.com. You scanned help.target.com and found a Stored XSS.

The Question: What is the maximum impact?

The “Hired” Answer:

“The impact is full data compromise of api.target.com.

1. I use the Stored XSS on help to execute JS on all visitors.

2. My JS makes XHR requests to api.target.com.

3. Since api trusts help, the browser permits the read.

4. I can steal all data visible to the api endpoint for every user who visits the help page.”

🎭 Scenario 3: The Intranet Scan

Context: You are on an external red team. You know the company uses an internal ticketing system at 10.0.0.5. You suspect it allows wildcard CORS.

The Question: How do you exploit this without VPN access?

The “Hired” Answer:

“I will use a Drive-By CORS attack.

1. I host a malicious website (e.g., a watering hole or phishing link).

2. When an employee visits, my JS attempts to fetch http://10.0.0.5/tickets.

3. If the internal server sends Access-Control-Allow-Origin: *, the browser allows my external script to read the internal response.

4. My script sends the ticket data back to my external C2 server.”

🎭 Scenario 4: The Credentials Mismatch

Context: A developer sets Access-Control-Allow-Origin: * AND Access-Control-Allow-Credentials: true.

The Question: Is this exploitable?

The “Hired” Answer:

“Technically, no, because browsers block this configuration entirely. It violates the CORS spec. The browser will throw a console error and refuse to show the response to the JavaScript. The developer effectively broke their own API, but they didn’t create a data leak vulnerability (unless they use a very old or non-compliant browser).”

🎭 Scenario 5: The “Public” API

Context: You found Access-Control-Allow-Origin: * on api.weather.com. It returns public weather data.

The Question: Is this a finding?

The “Hired” Answer:

“No. CORS protections are for private, user-specific data. Public data should be accessible by everyone. Unless the API also returns sensitive user info (like ‘My Saved Locations’) mixed with the public data, ACAO: * is the correct configuration for a public API.”

🛑 Summary of Part 1

1. Concept: CORS relaxes SOP. Misconfigurations break isolation.

2. Vulnerabilities: Reflected Origins, null Origin whitelisting, Weak Regex.

3. Advanced Vectors: Exploiting Trust Relationships (XSS), Breaking TLS via HTTP trust, and Intranet data theft.

4. Defense: Strict, server-side validation of the Origin header against a hardcoded whitelist.