cors

CORS Misconfiguration Detection

Overview

Cross-origin resource sharing is a controlled relaxation of the same-origin policy: by default a browser lets a page send a cross-origin request but forbids its script from reading the response, and CORS response headers name the origins allowed to read it and whether credentials may be included. The vulnerability is never in the mechanism but in the server's trust decision — reflecting whatever origin the request carried, matching an allowlist with sloppy string logic, trusting the literal null origin, or trusting an insecure scheme. When such a policy also permits credentials, any page the victim visits can issue a cookie-bearing request to the application, read the authenticated response, and forward it to the attacker: session-scoped records, API keys, personal data, and anti-forgery tokens that unlock further attacks. A wildcard policy on an internal service is a related pivot — the victim's browser becomes a proxy into a network the attacker cannot otherwise reach. This skill locates every place cross-origin headers are produced or origins are validated, checks each one in parallel, and merges results into <output_dir>/cors-results.md.

What it is NOT

• Cross-site request forgery (/websec:csrf): these are opposites and are constantly confused. A permissive sharing policy grants read access; it does not let an attacker forge a state change, and forgery needs no such policy because an HTML form does the job. Test: does the attack depend on reading the response body? Yes is this class; no is /websec:csrf. Never report a permissive policy as a forgery defence gap, and never claim a restrictive one prevents forgery.
• Information disclosure (/websec:information-disclosure): there the application volunteers data to anyone — a debug page, a backup, a verbose error. Here the data is properly protected by authentication, and the flaw is that a third-party origin is permitted to read it through the victim's session. If the endpoint returns sensitive data with no authentication at all, the header is secondary and the finding belongs there.
• Broken access control (/websec:access-control): if the server would return another user's data to a direct request, the missing ownership check is the bug; sharing headers only decide who may read a response the server already agreed to produce.
• Server-side request forgery (/websec:ssrf): a browser-driven pivot into an internal network via a permissive policy is this class; the server itself making an attacker-chosen request is /websec:ssrf.
• Script injection on an allowlisted origin (/websec:xss): a correct allowlist still creates a trust link, and injection on a trusted origin defeats it. The injection itself belongs to /websec:xss; record here that the allowlist entry inherits that risk.
• Cross-document messaging origin checks (/websec:dom-based): a message listener that fails to compare event.origin is a client-side taint problem, not a response-header policy.
• Socket handshake origin checks (/websec:websockets): sharing headers are the browser's read policy on an HTTP response; a socket upgrade is not covered by them, which is why the server must compare Origin itself. Test: is the control an HTTP response header the browser enforces (here), or an origin comparison the server performs at the upgrade (there)?
• Not a finding: same-origin traffic, which needs no header at all; a wildcard on genuinely public, unauthenticated, non-sensitive data — browsers refuse to expose a credentialed response under a wildcard, so nothing authenticated leaks; origin reflection on an endpoint that returns nothing an unauthenticated caller could not already fetch; a documented allowlist of exact origins the organisation controls; a preflight response that permits methods and headers but whose actual response carries a correctly restricted origin.