cors-cross-origin-misconfiguration

SKILL: CORS Misconfiguration — Credentialed Origins, Reflection, and Trust Boundary Errors

AI LOAD INSTRUCTION: Use this skill when browsers can access authenticated APIs cross-origin. Focus on reflected origins, credentialed requests, wildcard trust, parser mistakes, and origin allowlist bypasses. For JSONP hijacking deep dives, same-origin policy internals, honeypot de-anonymization, and CORS vs JSONP comparison, load the companion SCENARIOS.md.

Extended Scenarios

Also load SCENARIOS.md when you need:

• JSONP hijacking complete attack scenario — watering hole + <script> cross-origin data theft
• Honeypot de-anonymization via JSONP — use social platform JSONP endpoints to identify anonymous visitors
• Same-origin policy deep dive — protocol/hostname/port definition, document.domain subdomain relaxation and its security risks
• CORS vs JSONP technical comparison — methods, error handling, credential behavior, migration path
• CORS exploitation payloads — reflected origin with credentials: include, null origin via sandboxed iframe
• Dual-site attack lab pattern — localhost:8981 (target) + localhost:8982 (attacker) testing setup

1. WHEN TO LOAD THIS SKILL

Load when:

• Responses contain Access-Control-Allow-Origin, Access-Control-Allow-Credentials, or preflight headers
• A browser-based attack path might read authenticated API responses
• JSON endpoints appear protected from CSRF but are readable cross-origin

2. HIGH-VALUE MISCONFIGURATION CHECKS

3. QUICK TRIAGE

1. Send crafted Origin headers and inspect reflection.
2. Test with and without credentials.
3. Probe allowlist bypasses using attacker subdomains and parser edge cases.
4. If readable data is sensitive, chain to account or tenant impact.

4. RELATED ROUTES

• Session or JSON action abuse: csrf cross site request forgery
• OAuth token leakage and callback binding: oauth oidc misconfiguration
• API auth context: api auth and jwt abuse

5. NULL ORIGIN EXPLOITATION

How Origin: null is sent

Exploitation

If the server includes null in its origin allowlist or reflects it:

Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true

<iframe sandbox="allow-scripts allow-forms" srcdoc

The sandboxed iframe sends Origin: null → server reflects null → attacker reads credentialed response.

6. SUBDOMAIN XSS → CORS BYPASS CHAIN

Attack flow

PoC (injected via XSS on blog.target.com)

Why this works

• blog.target.com is same-site with api.target.com → SameSite cookies sent
• CORS allowlist includes *.target.com → Access-Control-Allow-Origin: https://blog.target.com
• Combined: SameSite bypass + CORS read = full API access from XSS on any subdomain

Reconnaissance for this chain

7. VARY: ORIGIN CACHING ISSUE

Problem

When the server reflects Origin in Access-Control-Allow-Origin but does not include Vary: Origin in the response, intermediary caches (CDN, reverse proxy) may serve the same cached response to different origins:

Detection

Exploitation

Fix verification

8. REGEX BYPASS PATTERNS

Common flawed regex patterns for origin validation:

Test payloads for origin validation bypass

Advanced: Unicode normalization bypass

Some origin validators normalize Unicode after comparison, while the browser sends the original — or vice versa.

9. INTERNAL NETWORK CORS EXPLOITATION

Scenario

An internal-only API (e.g., http://192.168.1.100:8080/admin) is configured with:

Internal APIs often use wildcard CORS because "only internal users can reach it."

Attack chain

Port scanning via CORS timing

Even without Access-Control-Allow-Origin: *, the attacker can infer internal service availability:

• Port open: connection established → CORS error (different timing)
• Port closed: connection refused → fast error
• Host down: timeout → slow error

Combined with DNS rebinding