Origin values, weak origin validation, trusting null, or allowing origins that attackers can control.Not every permissive CORS response is an exploitable vulnerability. The real risk depends on what origin is trusted, whether the browser sends useful credentials, what the endpoint returns, and whether attacker-controlled JavaScript can actually read sensitive data.
CORS is a browser security mechanism, not authentication.
CORS controls whether browser JavaScript can read certain cross-origin responses. It does not stop curl, Postman, backend services, or other non-browser clients from sending requests. Authentication and authorization must still be enforced by the application.
What Is a CORS Misconfiguration?
A CORS misconfiguration is an unsafe Cross-Origin Resource Sharing policy that gives an origin more browser access than intended. If an attacker-controlled origin is trusted, JavaScript running on the attacker’s site may be able to read responses from the vulnerable application.
Browsers normally apply the Same-Origin Policy to restrict one origin from reading responses belonging to another. CORS provides a controlled way for a server to relax that restriction by returning headers such as Access-Control-Allow-Origin.
For example, a legitimate application might intentionally allow:
Origin: https://app.example.com Access-Control-Allow-Origin: https://app.example.comThe problem begins when the server makes the same trust decision for an attacker-controlled origin:
Origin: https://attacker.example Access-Control-Allow-Origin: https://attacker.example Access-Control-Allow-Credentials: trueIf the endpoint returns sensitive authenticated information and the browser is permitted to include the necessary credentials, the attacker may be able to read that response from JavaScript running on attacker.example.
CORS is therefore a trust policy between browser origins. It is especially important on APIs used by browser applications, which is why CORS should be reviewed as part of broader REST API security.
How Do CORS and the Same-Origin Policy Work?
The Same-Origin Policy restricts browser scripts from freely reading data from a different origin. CORS lets the destination server explicitly tell the browser which external origins may read its responses.
An origin is defined by its scheme, hostname, and port. These are different origins:
https://example.comhttp://example.comhttps://api.example.comhttps://example.com:8443
What Does Access-Control-Allow-Origin Do?
Access-Control-Allow-Origin tells the browser which origin may access the response.
Access-Control-Allow-Origin: https://app.example.comIf JavaScript running on https://app.example.com makes the request, the browser can expose the response to that script when the rest of the CORS requirements are satisfied.
What Does Access-Control-Allow-Credentials Do?
Access-Control-Allow-Credentials: true allows a CORS response to be exposed for a credentialed request when the request and browser credential rules permit it.
Access-Control-Allow-Origin: https://app.example.com Access-Control-Allow-Credentials: trueThis becomes dangerous when the allowed origin is attacker-controlled and the endpoint returns sensitive data associated with the victim.
Credentials do not mean every cookie will automatically be sent.
Browser cookie rules such as SameSite, cookie scope, request context, and the application’s authentication design still affect whether useful credentials accompany the request.
What Is a CORS Preflight Request?
A preflight is an OPTIONS request the browser may send before certain cross-origin requests to determine whether the requested method and headers are permitted.
OPTIONS /api/account HTTP/1.1 Origin: https://app.example.com Access-Control-Request-Method: PUT Access-Control-Request-Headers: Authorization, Content-TypeA successful preflight is not authorization. It only tells the browser that the cross-origin request meets the server’s CORS policy. The application must still authenticate the user and authorize the requested operation.
When Is a CORS Misconfiguration Actually Exploitable?
A CORS configuration becomes a meaningful vulnerability when an attacker-controlled origin can use the victim’s browser to read data or reach resources the attacker should not be able to access directly. A suspicious header alone is not enough.
| CORS Condition | What Else Must Be True? | Potential Impact | Common False Positive |
|---|---|---|---|
| Arbitrary origin reflection with credentials | Victim has useful browser credentials, endpoint returns sensitive information, and the attacker can cause a request from an accepted origin | Authenticated data exposure, token leakage, or follow-on account compromise | The browser does not send usable credentials or the endpoint contains no sensitive data |
| Arbitrary origin reflection without credentials | The endpoint exposes information that matters even without authenticated credentials | Unauthorized cross-origin reading | The response is intentionally public |
Access-Control-Allow-Origin: * |
The exposed resource contains data an arbitrary external site should not be able to read without credentials | Exposure of unauthenticated or internal data | Public API or public asset intentionally readable by anyone |
Trusted null origin |
An attacker can create a null origin context and the target exposes useful data under that trust relationship |
Cross-origin reading of sensitive responses | null is returned but no sensitive response is accessible |
| Weak regex, prefix, or suffix validation | An attacker can control an origin that passes the flawed validation | Same impact as trusting an arbitrary attacker origin | The validation looks broad but no attacker-controlled domain can actually match it |
| All subdomains trusted | An attacker gains control or script execution on one trusted subdomain | Sensitive API responses can become readable from that subdomain | No trusted subdomain is attacker-controllable |
| HTTP origin trusted by HTTPS application | Attacker can interfere with the victim’s unencrypted HTTP traffic | Sensitive HTTPS responses may become readable through the trusted HTTP origin | No practical network position exists to control the HTTP origin |
Authentication design also changes exploitability. Cookie-authenticated endpoints may allow the browser to contribute credentials automatically when cookie rules permit it, while APIs that require an attacker-unknown bearer token are usually harder to exploit directly. Token refresh, session bootstrap, and other endpoints that issue or renew those credentials should still be tested separately.
Finding vs vulnerability
A scanner can identify origin reflection or an overly broad policy. Severity should then be based on whether the behavior creates a real browser-accessible path to sensitive data, not on the presence of the header alone.
What Are the Most Common CORS Misconfigurations?
The most important CORS weaknesses are arbitrary origin reflection, weak origin validation, unsafe trust in related origins, null origin trust, insecure HTTP origins, and wildcard policies applied to data that should not be public.
1. Reflecting Any Origin
The clearest dangerous pattern is blindly copying the request’s Origin value into the response.
Origin: https://attacker.example Access-Control-Allow-Origin: https://attacker.example Access-Control-Allow-Credentials: trueIf the application does this for any supplied origin, the CORS policy is effectively delegating trust to the requester instead of checking an allowlist.
2. Weak Regex, Prefix, or Suffix Validation
Origin validation must compare the complete allowed origin, not whether the string merely starts or ends with a trusted-looking value.
For example, logic intended to trust:
https://example.commay accidentally accept attacker-controlled values such as:
https://example.com.attacker.exampleor other lookalike origins if the validation uses an unsafe regular expression or string check.
3. Trusting Every Subdomain
Allowing all subdomains is not automatically vulnerable, but every trusted subdomain becomes part of the security boundary.
If api.example.com trusts *.example.com and an attacker gains JavaScript execution on old.example.com, the attacker may be able to use that trusted origin to read CORS-protected API responses.
This is one reason cross-site scripting (XSS) on a trusted subdomain can increase the impact of an otherwise legitimate CORS trust relationship.
4. Trusting the null Origin
Origin: null can appear for opaque origins such as some sandboxed documents and certain non-hierarchical schemes. Applications should not treat null as a universally safe local origin.
Origin: null Access-Control-Allow-Origin: null Access-Control-Allow-Credentials: trueIf an attacker can create a browser context that generates a null origin and the server trusts it for sensitive responses, the CORS policy may be exploitable.
5. Trusting HTTP Origins From an HTTPS Application
An HTTPS application weakens its trust boundary if it allows a related origin over plain HTTP to access sensitive responses.
Access-Control-Allow-Origin: http://legacy.example.com Access-Control-Allow-Credentials: trueAn attacker capable of interfering with the victim’s HTTP traffic may be able to control the trusted HTTP origin and use it to make CORS requests to the HTTPS application.
6. Using Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: * is not automatically a vulnerability. It is appropriate for resources intentionally readable by every origin, such as many public APIs and static assets, Wildcard CORS can still matter without credentials when the resource is not genuinely public. For example, an unauthenticated internal application may rely on network location or IP restrictions rather than application authentication. An external page could potentially use a victim’s browser to reach and read that internal resource if browser and network conditions allow it.
Access-Control-Allow-Origin: *The important question is whether the response contains information that arbitrary websites should not be able to read.
Wildcard CORS does not work for credentialed browser responses.
If a request uses credentials, browsers require an explicit allowed origin. A response using Access-Control-Allow-Origin: * cannot be exposed to JavaScript as a credentialed CORS response.
What Does an Exploitable CORS Misconfiguration Look Like?
A common exploitable case is an authenticated API that reflects an attacker-controlled origin and permits credentialed CORS.
The victim’s browser sends:
GET /api/account HTTP/1.1 Host: victim.example Origin: https://attacker.example Cookie: session=...The vulnerable server responds:
HTTP/1.1 200 OK Access-Control-Allow-Origin: https://attacker.example Access-Control-Allow-Credentials: true Content-Type: application/json {"email":"[email protected]","accountId":"48291"}If the browser’s credential rules allow the authenticated request, JavaScript hosted on attacker.example can request the endpoint and read the response:
fetch("https://victim.example/api/account", { credentials: "include" }) .then(response => response.text()) .then(data => { // Attacker-controlled page can now read the returned data. });The vulnerability is not simply that the server returned a CORS header. The problem is the complete chain:
- The attacker controls an origin accepted by the target.
- The victim opens content on that origin.
- The victim’s browser can send the relevant authenticated request.
- The target returns sensitive information.
- The CORS policy tells the browser that the attacker origin may read the response.
What Can an Attacker Do With a CORS Vulnerability?
An exploitable CORS vulnerability can expose any sensitive response that the affected origin is allowed to read. The impact depends entirely on the endpoint and authentication context.
- Read account information. Profile details, email addresses, identifiers, billing information, or other authenticated API data may become visible.
- Expose security tokens. APIs that return CSRF tokens, API keys, temporary credentials, or other secrets may leak them cross-origin.
- Enable follow-on account compromise. If the exposed information includes reset tokens, privileged API credentials, or data usable in another attack, the impact can extend beyond information disclosure.
- Reach internal resources. A victim’s browser may be able to reach an intranet or localhost resource that the remote attacker cannot access directly.
- Expand another vulnerability. XSS or subdomain takeover on an otherwise trusted origin can provide the attacker with the origin required to exploit the CORS trust relationship.
Severity is endpoint-specific.
Allowing every origin to read a public product catalog is not equivalent to allowing an attacker-controlled origin to read an authenticated account endpoint. The headers may look similar while the security impact is completely different.
What Do Real CORS Vulnerabilities Look Like?
Real CORS vulnerabilities range from sensitive-data exposure to multi-stage attack chains. The useful lesson is that impact comes from the resource exposed through the trust relationship, not from the header alone.
CVE-2022-25227: Thinfinity VNC
Thinfinity VNC contained a CORS-related weakness that could expose information used in a larger attack chain. The case is useful because it shows how a browser trust flaw can become much more serious when the returned data enables additional interaction with another service.
CVE-2019-16517: ConnectWise Control
A ConnectWise Control issue involved unsafe handling of cross-origin trust that allowed an arbitrary origin to interact with application APIs. The case demonstrates why blindly reflecting origins can become dangerous when administrative or sensitive application functionality is reachable.
Permissive CORS Without Impact
The opposite case matters just as much. A server can reflect arbitrary origins and still have no meaningful CORS vulnerability if the exposed response contains only public information.
HackerOne’s current guidance specifically lists permissive CORS configurations without demonstrated security impact among findings that are generally considered theoretical rather than valid vulnerabilities.
This is why CORS testing should prove what the browser can actually read and what that data allows an attacker to do.
How Do You Check for CORS Misconfiguration?
Test each sensitive endpoint with origins the application should not trust, then confirm suspicious behavior in a real browser. Do not stop after seeing an unusual header in curl.
- Identify endpoints that return CORS headers: Focus first on authenticated APIs, account data, administration functions, token endpoints, and internal application APIs.
- Send a completely unrelated Origin: Use a domain the application should never trust.
Origin: https://attacker.exampleIf the server reflects that origin into
Access-Control-Allow-Origin, investigate further. - Test prefix and suffix bypasses: If the expected origin is
https://example.com, check whether validation accidentally accepts attacker-controlled lookalike origins. - Test related subdomains: Determine whether the policy trusts all subdomains and whether any trusted subdomain can be controlled through XSS, takeover, or unsafe hosting.
- Test known related and trusted origins: Do not assume the application will reveal its CORS policy when you test only its own domain or a random origin. Some endpoints enable CORS only for a specific frontend, sibling application, legacy domain, or partner origin. Test known related origins and then check whether their validation can be bypassed.
- Test Origin: null when relevant: If the server explicitly accepts
null, determine whether an attacker can create a suitable opaque-origin browser context and read sensitive data. - Check credential behavior: Look for
Access-Control-Allow-Credentials: true, but also verify whether the victim’s actual authentication credentials would be sent under current browser cookie rules. - Check dynamic-origin caching: If the application dynamically returns a specific ACAO value based on the incoming origin, verify that the response uses
Vary: Originso shared caches do not reuse the wrong origin-dependent response metadata. - Verify the finding in a browser: Use an authorized controlled origin and confirm whether browser JavaScript can actually read the sensitive response.
This workflow fits within broader API vulnerability scanning, but CORS findings need browser context before severity is assigned.
Can curl Prove a CORS Vulnerability?
No. curl can reveal an unsafe-looking CORS policy, but it does not enforce the browser’s Same-Origin Policy or CORS rules and therefore cannot by itself prove browser exploitability.
For example:
curl -i \ -H "Origin: https://attacker.example" \ https://target.example/api/accountcurl is useful for checking:
- whether arbitrary origins are reflected;
- whether
nullis accepted; - whether wildcard CORS is enabled;
- whether
Access-Control-Allow-Credentialsis returned; - whether prefix or suffix origin variations pass validation;
- how preflight requests are answered.
But curl will show you a response even when a browser would refuse to expose that response to cross-origin JavaScript.
Can a Vulnerability Scanner Detect CORS Misconfiguration?
Yes. A scanner can detect many CORS weaknesses by varying the Origin header and analyzing the server’s response, but complex trust relationships and real browser exploitability may still require contextual or browser-based validation.
| Testing Method | Good At | Main Limitation |
|---|---|---|
| curl / Postman | Manipulating Origin values and inspecting CORS headers | Does not enforce browser SOP or CORS |
| DAST | Detecting reflection, wildcards, null trust, and weak origin patterns at scale | May lack enough context to prove sensitive browser impact |
| Browser-aware DAST | Confirming real browser access and cross-origin reads | Authentication state and complex workflows can limit coverage |
| SAST / configuration review | Finding unsafe reflection logic, weak regexes, and dangerous middleware configuration | May not see CDN, reverse proxy, gateway, or runtime policy changes |
| Manual penetration testing | Complex trust chains involving subdomains, XSS, SameSite behavior, and application-specific impact | Slower than automated testing |
This is why CORS works well as an example of the difference between identifying suspicious behavior and proving exploitability. ScanTitan’s guide to vulnerability scanning vs penetration testing covers that distinction in more detail.
For APIs specifically, API security testing should combine response analysis with authentication, authorization, input handling, and application-specific behavior rather than treating CORS as an isolated header check.
Is CORS Misconfiguration in the OWASP Top 10?
CORS misconfiguration is covered by OWASP guidance, but it is not a standalone OWASP Top 10 category.
In the OWASP API Security Top 10:2023, API8 Security Misconfiguration explicitly lists a missing or improperly configured CORS policy as an example of security misconfiguration.
In the general OWASP Top 10:2025, A02 Security Misconfiguration includes CWE-942, Permissive Cross-domain Policy with Untrusted Domains, among its mapped weaknesses.
OWASP also maintains a dedicated CORS testing entry in the Web Security Testing Guide: WSTG-CLNT-07 Cross Origin Resource Sharing.
The practical classification depends on what failed: CORS may appear as a configuration weakness, and the resulting exposure may also create an access-control problem. The important point is to describe the actual trust failure rather than treating CORS as its own OWASP category.
What Is the Difference Between CORS, CSRF, and the Same-Origin Policy?
SOP restricts cross-origin reading, CORS selectively relaxes that restriction, and CSRF abuses the browser’s ability to send an unintended request. They interact, but they solve different problems.
| Concept | What It Does | Primary Security Question |
|---|---|---|
| Same-Origin Policy | Restricts browser scripts from reading resources belonging to another origin | Can this origin read data belonging to another origin? |
| CORS | Allows a server to relax SOP for selected origins | Which external origins should the browser allow to read this response? |
| CSRF | Tricks a victim browser into sending an unwanted authenticated request | Can an attacker cause the victim to perform an action? |
CORS is not a CSRF defense. A browser may be able to send a cross-origin request even when SOP prevents the attacker from reading its response. Protect state-changing actions with appropriate server-side authorization and CSRF defenses rather than relying on CORS.
How Do You Fix a CORS Misconfiguration?
Fix CORS by allowing only the exact origins that genuinely need browser access, removing unnecessary credentialed trust, and validating the policy against attacker-controlled origins after deployment.
- List every legitimate browser origin.Identify the frontend applications that actually need cross-origin access. Do not start from “allow everything” and try to restrict it later.
- Match the complete origin.Validate the full scheme, hostname, and port against a controlled allowlist.
- Do not blindly reflect Origin.Return the request’s origin only after confirming it exactly matches an approved origin.
- Remove null unless it is genuinely required.Do not use
Access-Control-Allow-Origin: nullas a convenient development workaround in production. - Use credentialed CORS only where needed.If the browser does not need cookies or other credentials for a cross-origin integration, do not enable
Access-Control-Allow-Credentials: true. - Do not trust insecure HTTP origins for sensitive HTTPS APIs.Keep trusted browser origins on HTTPS so the trust relationship does not depend on plaintext network traffic.
- Audit wildcard and subdomain trust.If many subdomains are trusted, verify that abandoned, third-party-hosted, development, and user-controlled subdomains cannot become attacker origins.
- Restrict methods and headers to what the application requires.Do not expose unnecessary cross-origin capabilities simply because the framework makes them easy to enable.
- Use Vary: Origin for dynamic explicit origins.When the server returns different ACAO values depending on the request origin, include
Vary: Originso caches know the response varies by origin. - Keep authentication and authorization server-side.Never treat an allowed
Originvalue as proof that the requester is authorized to access sensitive data. - Re-test using untrusted origins and a real browser.Confirm that rejected origins cannot read sensitive responses after the fix.
Secure pattern
Maintain a small explicit allowlist, validate the complete origin, enable credentials only where required, and continue enforcing normal authentication and authorization on every protected endpoint.
Need to Check Your Application for CORS and API Security Issues?
If you are unsure whether your application accepts untrusted origins, ScanTitan can help identify externally observable CORS behavior alongside other web and API security weaknesses.
A useful CORS assessment should do more than flag Access-Control-Allow-Origin. It should test origin handling, compare trusted and untrusted values, identify credential-related exposure, and distinguish a permissive configuration from a finding with meaningful security impact.
Scan for application vulnerabilities
Use the ScanTitan Website Vulnerability Scanner to identify exposed web security weaknesses and investigate risky application behavior.
Testing an API?
Start with our API security testing guide to review CORS together with authentication, authorization, input validation, endpoint exposure, and other API attack paths.
CORS Misconfiguration FAQ
What is a CORS misconfiguration?
A CORS misconfiguration is an unsafe cross-origin policy that allows an origin to read browser responses it should not be permitted to access. Common causes include arbitrary origin reflection, weak allowlist validation, trusting null origins, and overly broad subdomain trust.
Is CORS misconfiguration always a vulnerability?
No. A permissive CORS policy becomes a meaningful vulnerability when it gives an attacker-controlled origin access to sensitive information or functionality that should not be available cross-origin. Public data intentionally exposed to every origin may legitimately use permissive CORS.
How do I check for CORS misconfiguration?
Send requests to sensitive endpoints using untrusted Origin values and inspect Access-Control-Allow-Origin and Access-Control-Allow-Credentials. Test random origins, prefix and suffix variations, related subdomains, null where relevant, and then verify suspicious behavior in a real browser.
Is Access-Control-Allow-Origin: * a vulnerability?
Not by itself. Wildcard ACAO is appropriate for resources intentionally readable by every origin. It becomes a concern when it exposes data that arbitrary websites should not be able to read, including some internal or otherwise restricted unauthenticated resources.
Can Access-Control-Allow-Origin: * be used with credentials?
Not for a credentialed CORS response exposed to browser JavaScript. Browsers require a specific allowed origin for credentialed CORS and block access when Access-Control-Allow-Origin is the wildcard.
Can CORS misconfiguration lead to account takeover?
It can contribute to account takeover when a vulnerable CORS policy exposes sensitive information such as privileged tokens, reset data, API credentials, or other information that enables a follow-on attack. CORS misconfiguration alone does not automatically mean account takeover is possible.
Can curl detect a CORS vulnerability?
curl can detect suspicious CORS response behavior such as origin reflection, wildcard policies, null trust, and weak validation, but it cannot enforce the browser’s Same-Origin Policy. Browser testing is required to confirm whether attacker-controlled JavaScript can actually read the response.
What is the difference between CORS and CSRF?
CSRF is about causing a victim browser to send an unwanted request. CORS primarily controls whether browser JavaScript can read a cross-origin response. CORS is not a replacement for CSRF defenses.
Is CORS misconfiguration in the OWASP Top 10?
CORS misconfiguration is covered by OWASP but is not a standalone OWASP Top 10 category. OWASP API Security Top 10:2023 includes improperly configured CORS under API8 Security Misconfiguration, while current OWASP guidance also maps permissive cross-domain policies to broader access-control and security-misconfiguration categories.
How do I fix a CORS misconfiguration?
Use an explicit allowlist of required origins, validate the full scheme, host, and port, avoid blindly reflecting Origin, remove unnecessary null or wildcard trust, enable credentials only when required, use HTTPS origins, keep authorization server-side, and re-test rejected origins in a browser.
