CORS Misconfiguration
detect, understand, remediate
CORS misconfiguration occurs when overly permissive cross-origin resource sharing policies allow malicious websites to read sensitive data from your application on behalf of authenticated users.
No credit card required. Free plan available forever.
What is a CORS misconfiguration?
Cross-Origin Resource Sharing (CORS) is a browser security mechanism that controls which external domains can access resources on your web server. A CORS misconfiguration occurs when the server's Access-Control-Allow-Origin policy is overly permissive, allowing untrusted origins to make authenticated cross-origin requests and read sensitive responses.
When CORS is misconfigured, an attacker can host a malicious page that makes cross-origin requests to your API using the victim's authenticated session. Unlike CSRF (which can only send requests), CORS misconfigurations allow the attacker to read the response, enabling theft of sensitive data, API keys, personal information, and session tokens.
CORS misconfigurations are particularly dangerous because they are invisible to users and can be exploited silently. The victim simply visits a malicious page, and their browser, acting on the overly permissive CORS headers, sends authenticated requests to the target API and hands the responses back to the attacker's JavaScript.
How it works
Identify permissive CORS
Attacker discovers that the target API reflects the Origin header in Access-Control-Allow-Origin, or uses a wildcard with credentials.
Host malicious page
A page is created on the attacker's domain containing JavaScript that makes cross-origin fetch/XHR requests to the target API.
Victim visits attacker page
The victim, who is authenticated on the target site, visits the attacker's page. Their browser sends the cross-origin request with cookies attached.
Response data stolen
Because the CORS policy permits the attacker's origin, the browser allows JavaScript to read the response containing the victim's sensitive data.
Common causes
Reflecting the Origin header
Dynamically setting Access-Control-Allow-Origin to whatever Origin the browser sends, effectively allowing every domain in the world to make authenticated requests.
Wildcard with credentials
Setting Access-Control-Allow-Origin to * alongside Access-Control-Allow-Credentials: true. While browsers block this combination, similar misconfigurations bypass protections.
Trusting all subdomains
Allowing any subdomain (*.example.com) without considering that a compromised or attacker-controlled subdomain can exploit the trust relationship.
Weak origin validation
Using prefix or suffix matching for origin validation (e.g. allowing evil-example.com because it ends with example.com) instead of exact string comparison.
How to detect it
Automated detection
- SecPortal's external scanner tests CORS headers by sending requests with various Origin values and checking if they are reflected
- Security header analysis flags missing or overly permissive Access-Control-Allow-Origin configurations
- Code scanning identifies server-side CORS configuration patterns that dynamically reflect origins without allow-list validation
Manual testing
- Send requests with arbitrary Origin headers and check if the response mirrors the value in Access-Control-Allow-Origin
- Test with null Origin (used by sandboxed iframes and local files) to see if null is accepted as an allowed origin
- Verify whether Access-Control-Allow-Credentials is set alongside permissive origin policies, enabling cookie-based authentication bypass
How to fix it
Use a strict allow-list of origins
Maintain an explicit list of trusted origins and only set Access-Control-Allow-Origin when the request's Origin exactly matches an entry in the list.
Never reflect arbitrary origins
Do not dynamically set the ACAO header to whatever Origin the browser sends. This is equivalent to allowing every website to make authenticated requests to your API.
Avoid wildcard with credentials
Never combine Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true. If credentials are needed, use explicit origin validation.
Validate the Origin header server-side
Perform exact string comparison of the Origin header against your allow-list. Avoid regex or prefix/suffix matching which can be bypassed with crafted domains.
Compliance impact
Detect CORS issues automatically
SecPortal's header checker identifies overly permissive CORS policies and missing security headers. Start free.
No credit card required. Free plan available forever.