CORS Misconfiguration
debt(d5/e3/b3/t7)
Closest to 'specialist tool catches' (d5). The term's detection_hints list semgrep, burpsuite, and owasp-zap as tools that can detect CORS misconfigurations. These are specialized security scanners (SAST/DAST), not default linters, placing this squarely at d5.
Closest to 'simple parameterised fix' (e3). The quick_fix says to audit every Access-Control-Allow-Origin header and reject unlisted origins rather than reflecting them. This involves replacing a pattern (origin reflection) with a safer alternative (allowlist validation), typically touching a small number of middleware or header-setting locations within one component.
Closest to 'localised tax' (b3). CORS configuration typically lives in middleware or a central API layer. While it applies to web/api contexts, it doesn't impose ongoing maintenance burden across the entire codebase — it's a localized policy decision that, once fixed, doesn't shape future development significantly.
Closest to 'serious trap' (t7). The misconception field explicitly states that developers believe 'CORS is a server-side security control' when in fact it's browser-enforced and doesn't protect against non-browser clients. This directly contradicts how developers familiar with server-side security patterns expect it to work. Additionally, common_mistakes show multiple gotchas (substring matching, credential behavior) that trap developers who assume CORS works like other security mechanisms.
Also Known As
TL;DR
Explanation
CORS misconfigurations arise when servers echo back arbitrary Origin headers in Access-Control-Allow-Origin, or set it to *, while also allowing credentials via Access-Control-Allow-Credentials: true. A malicious website can then make authenticated cross-origin requests and read the responses — stealing session data, CSRF tokens, or sensitive API responses. In PHP, explicitly whitelist allowed origins rather than reflecting input, and never combine wildcard origins with credentials.
Common Misconception
Why It Matters
Common Mistakes
- Reflecting the incoming Origin header back as Access-Control-Allow-Origin without validating against a whitelist.
- Sending Access-Control-Allow-Origin: * alongside Access-Control-Allow-Credentials: true — browsers reject this but many developers don't notice until a browser change.
- Whitelisting by substring check — an attacker registers evil-yoursite.com.
- Allowing credentials in CORS for non-sensitive endpoints, then adding sensitive data to those endpoints later.
Code Examples
header('Access-Control-Allow-Origin: ' . $_SERVER['HTTP_ORIGIN']); header('Access-Control-Allow-Credentials: true');$allowed = ['https://trusted.example.com']; if (in_array($_SERVER['HTTP_ORIGIN'], $allowed)) { header('Access-Control-Allow-Origin: ' . $_SERVER['HTTP_ORIGIN']); }