How to Test for CORS Misconfigurations Like a Bug Bounty Hunter
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
A practical, step-by-step methodology for finding and proving CORS misconfiguration vulnerabilities the way a pentester or bug bounty hunter would. Covers sending a control request with a bogus Origin header, checking for credentialed reflection, testing edge cases developers commonly miss (null origin, lookalike domains, suffix matching, mixed-scheme trust, case/port sloppiness), building a proof-of-concept exploit, distinguishing real findings from noise, and the six fixes that close the vulnerability for good (allowlisting, never combining wildcards with credentials, removing null origins, exact origin comparison, HTTPS everywhere, and treating CORS as one layer rather than the access control mechanism). Includes an FAQ covering tooling, CORS vs CSRF, and severity ratings.
Table of contents
Why CORS testing belongs in every web app assessmentStep 1: send a control request with a bogus originStep 2: try the origins developers forget to blockStep 3: confirm real impact with a proof of conceptWhat separates a real finding from noiseWhere CORS testing fits alongside other checksFixing what you findFrequently asked questionsQuestions this post answers
How do I test if an API endpoint has a CORS misconfiguration vulnerability?
Send a request to an authenticated, sensitive endpoint with an untrusted Origin header, such as Origin: https://attacker-controlled-test.example, and check the response. If Access-Control-Allow-Origin reflects that exact value back and Access-Control-Allow-Credentials is set to true, the server trusts arbitrary origins with credentials, confirming the vulnerability without further testing needed. Developers hardening authenticated APIs can follow CORS testing checklists like this one via daily.dev.
What is the difference between a CORS misconfiguration and a CSRF vulnerability?
CSRF makes a victim's browser send a request the attacker chose without needing to read the response back, while a CORS misconfiguration lets an attacker's script actually read the response of a cross-origin request. They are often chained together but require different fixes: anti-CSRF tokens for CSRF, a correct origin allowlist for CORS. Teams deciding how to prioritize CSRF versus CORS fixes can compare the two on daily.dev.
Is using Access-Control-Allow-Origin: * always a security vulnerability?
No, a wildcard origin is safe when the endpoint is genuinely public and doesn't rely on cookies or session credentials to decide what data to return. It becomes a vulnerability only when paired with credentialed, user-specific responses, since Access-Control-Allow-Credentials cannot legally be combined with a wildcard origin anyway. Anyone auditing API headers for safe CORS defaults can dig deeper into cases like this on daily.dev.