June 8, 2026
Understanding CORS Misconfiguration and How It Can Be Exploited
Before discussing CORS misconfigurations, it is important to understand what CORS is and why it exists.
Andrew Dehghan
2 min read
What Is CORS?
CORS (Cross-Origin Resource Sharing) is a browser security mechanism that allows a server to specify which origins are permitted to access its resources.
Contrary to a common misconception, CORS was not designed to remove the Same-Origin Policy (SOP). Instead, it provides a controlled way to relax SOP restrictions when cross-origin communication is required.
What Is the Same-Origin Policy?
The Same-Origin Policy is one of the core security controls implemented by browsers.
Under SOP, a website is not allowed to access the responses of another website if their origins differ.
An origin consists of three components:
- Protocol (HTTP or HTTPS)
- Domain
- Port
If any of these components differs, the browser treats the request as cross-origin.
Identifying CORS Usage
One of the simplest ways to determine whether an application uses CORS is to include an Origin header in a request.
If the response contains the following header:
Access-Control-Allow-OriginAccess-Control-Allow-Originthe application is likely using CORS.
However, for a CORS issue to become significantly more impactful, the following header is often required:
Access-Control-Allow-Credentials: trueAccess-Control-Allow-Credentials: trueThis header allows browsers to include credentials such as cookies when making cross-origin requests.
Testing for CORS Misconfigurations
CORS testing is typically performed after authentication because the most valuable targets are authenticated endpoints, such as user profile pages and sensitive APIs.
A common testing approach is:
- Send a request with the application's own origin.
- Observe the response headers.
- Verify whether the server returns:
Access-Control-Allow-Origin
Access-Control-Allow-Credentials: trueAccess-Control-Allow-Origin
Access-Control-Allow-Credentials: trueIf these headers are present, the application is using credentialed CORS.
The next step is to test alternative origins.
For example:
Origin: https://example-subdomain.comOrigin: https://example-subdomain.comIf the server accepts trusted subdomains, continue testing additional origins.
A particularly important test is using a completely unrelated domain:
Origin: https://hacker.comOrigin: https://hacker.comIf the server reflects or accepts arbitrary origins while allowing credentials, this may indicate a serious CORS misconfiguration.
Advanced Testing Scenarios
If arbitrary domains are rejected, additional test cases may still reveal weaknesses.
For example:
Testing the null Origin
Origin: nullOrigin: nullSome applications mistakenly trust requests with a null origin.
Testing Weak Origin Validation
Applications sometimes validate origins using insecure pattern matching or poorly implemented regular expressions.
Examples include:
https://hackertarget.comhttps://hackertarget.comor
https://target.com.hacker.comhttps://target.com.hacker.comIf these origins are accepted, the application's origin validation logic may be flawed.
Why Does This Matter?
In practice, CORS misconfigurations are most dangerous when the application relies on cookie-based authentication.
Because browsers automatically attach cookies to authenticated requests, a malicious website may be able to make authenticated cross-origin requests on behalf of a victim and access sensitive response data if the CORS policy is overly permissive.
This is why CORS should never be viewed as a simple header configuration issue. A small mistake in origin validation can expose authenticated resources and significantly increase the application's attack surface.