OSWA: Cross-Origin Resource Sharing (CORS) Misconfiguration

CORS misconfiguration tests whether a server reflects an untrusted Origin and permits credentialed reads. The exam focuses on the exact header combination that lets an attacker origin read authenticated responses.

Core rules and concepts

• The browser sends Origin; the server replies with Access-Control-Allow-Origin (ACAO) and optionally Access-Control-Allow-Credentials (ACAC).
• The dangerous combination is ACAO reflecting an arbitrary origin together with ACAC: true. Wildcard * cannot be used with credentials; browsers block that response.
• Trusting null is exploitable via sandboxed iframes and data URLs that send Origin: null.
• Regex flaws allow suffix or prefix tricks: target.com.evil.com, evil-target.com, or a subdomain takeover.
• Trusting any subdomain means XSS on that subdomain can read the main application's data.
• Preflight requests use OPTIONS with Access-Control-Request-Method and Access-Control-Request-Headers.

Worked example

Send GET /api/me with Origin: https://evil.com. The response includes Access-Control-Allow-Origin: https://evil.com and Access-Control-Allow-Credentials: true. From evil.com, run fetch('https://target/api/me',{credentials:'include'}) and read the JSON, which contains an API key. Reasoning: both required conditions are met, so the browser exposes the response. If ACAO were *, the credentialed read would fail regardless of ACAC.

Traps that cost marks

• Believing * with credentials works; browsers reject it.
• Testing without cookies, which hides the credentialed impact.
• Forgetting the null origin case.
• Missing regex bypasses using prefix or suffix domains.
• Confusing CORS with CSRF: CORS enables reading, CSRF enables sending.