CORS header configuration checker

Paste a header block and it confirms that Access-Control-Allow-Origin is present, detects the unsafe combination of a wildcard origin with credentials, and identifies a missing Vary: Origin signal for a specific allowed origin. The result is deterministic and explains every finding, making it useful during deployment reviews, incident investigation, automated configuration checks, and routine API hardening without sending a request to the target server.

Read the result as a focused configuration review

Start by copying the response headers exactly as a browser or command-line client received them, with one Name: value pair on each line. Header names are matched without regard to capitalization, and comma-separated Vary values are handled as individual tokens. The checker requires Access-Control-Allow-Origin because there is no CORS policy to assess without that response header; its absence therefore produces an input error instead of an inconclusive report. A successful report returns the normalized allowed origin, whether credentials are enabled, whether the response varies by Origin, and an ordered list of findings. The valid field means that no error-severity issue was detected. A warning can still be present, so consumers should also inspect issue_count and issues rather than treating valid as the only signal. This narrow output is intentional: it gives reviewers stable facts about two common mistakes without pretending to prove that an application’s entire authorization model is secure. Preserve the original response and request origin alongside the result when the check forms part of an audit record.

Understand wildcard origins and credentialed requests

Access-Control-Allow-Origin: * is convenient for genuinely public, non-credentialed resources because it permits any requesting origin to read the response. It must not be combined with Access-Control-Allow-Credentials: true. Browsers reject that pairing for credentialed CORS access, and the configuration often reveals that the server’s intended trust boundary was not expressed correctly. This checker records that combination as wildcard_origin_with_credentials with error severity. The remedy is not automatically to echo every incoming Origin. Instead, decide which origins are trusted, compare the request Origin against an explicit allowlist, and emit one approved origin only after a match. If cookies or other ambient credentials are unnecessary, disable credential support and keep the public wildcard policy. Also remember that CORS controls whether browser scripts can read a response; it is not authentication, authorization, request forgery protection, or a firewall. Review cookie attributes, authorization checks, methods, exposed headers, and preflight behavior separately before declaring the endpoint secure.

Use Vary: Origin to keep shared caches honest

When a server chooses a specific Access-Control-Allow-Origin value according to the request Origin, the response representation effectively depends on that request header. Vary: Origin tells browsers, reverse proxies, and content delivery caches that responses produced for different origins must not be treated as interchangeable. Without it, a cache can reuse a response carrying one tenant’s allowed origin for another request, causing intermittent failures and potentially undermining the policy assumptions around cached content. The checker therefore emits missing_vary_origin when the allowed origin is specific and neither Origin nor the wildcard token appears in Vary. It accepts Origin in a comma-separated Vary line and across repeated Vary headers. The finding is a warning because a pasted response cannot reveal whether the origin value is constant for every request or whether caching is disabled elsewhere. Confirm the server’s actual selection logic and cache directives before changing production behavior. If the origin is dynamically reflected after allowlist validation, adding Origin to Vary is generally the clearest and safest cache signal.