How a CORS Misconfiguration Allowed Cross-Origin API Response Access
- Devansh Patel
- 2 days ago
- 4 min read
How an Overly Permissive CORS Policy Can Allow Cross-Origin API Response Access
A CORS misconfiguration can allow an untrusted website to read API responses that should only be accessible to trusted application origins. During security testing, a permissive CORS policy was identified on an API endpoint where the server returned the following header:
Access-Control-Allow-Origin: *This configuration allowed a webpage hosted on a different origin to read the API response directly inside the browser.
All target details, endpoint names, payloads, and response values in this write-up have been sanitised. The example target used here is generic:
What Is CORS Misconfiguration?
CORS misconfiguration occurs when a server allows untrusted or unnecessary origins to access API responses through the browser.
CORS, or Cross-Origin Resource Sharing, is a browser security mechanism that decides whether one website can read responses from another website.
A browser may allow a cross-origin request to be sent. However, the browser should not allow the calling website to read the response unless the API explicitly permits it.
This distinction is important.
The security issue is not simply that a request can be made. The real issue is that an untrusted external origin can read a response that should only be available to trusted frontend applications.
Why Is Access-Control-Allow-Origin: * Risky?
The header below tells the browser that any website is allowed to read the API response:
Access-Control-Allow-Origin: *For public resources, this may be acceptable.
However, for API endpoints that return internal metadata, account-related data, user-specific information, tokens, documents, or private records, this becomes a serious security weakness.
In simple terms:
Any website → Browser → API response can be read
A safer trust model should be:
Trusted frontend only → Browser → API response can be read
Root Cause of the Vulnerability
The root cause was an overly permissive CORS policy.
Instead of allowing only trusted frontend origins, the API allowed every origin using a wildcard value:
Access-Control-Allow-Origin: *A safer configuration would allow only the trusted application origin:
Access-Control-Allow-Origin: https://app.example.com
Vary: OriginThe backend should validate the incoming Origin header against a strict allowlist before returning CORS headers.
Sanitised Proof of Concept
To verify the issue safely, a simple page was hosted on a separate origin and used to request the affected API endpoint.
Example attacker-controlled origin:
Example target API:
Sanitised PoC:
<script>
async function testCors() {
const response = await fetch("https://api.example.com/v1/resource");
const body = await response.text();
document.getElementById("output").innerText = body;
}
testCors();
</script>
<div id="output"></div>The PoC confirmed that the browser allowed the external page to read the API response body.
Sensitive values, the real endpoint path, and actual response data have intentionally been removed from this blog.
Security Impact of CORS Misconfiguration
A permissive CORS policy can expose API responses to untrusted websites.
If an attacker convinces a user to open a malicious page, that page may be able to read data from affected API endpoints in the user’s browser.
The impact depends on what the endpoint returns.
If the endpoint returns only public data, the issue may be low impact or not exploitable. If the endpoint returns internal metadata, account details, user-specific data, tokens, documents, or private records, the impact becomes more serious.
A clean impact statement would be:
Due to a permissive CORS policy, an untrusted external origin could read API responses from api.example.com. This may expose internal or sensitive data depending on the affected endpoint.
The severity should be based on the actual data exposed, not only on the presence of the CORS header.
Possible Impact
A CORS misconfiguration may lead to:
Cross-origin reading of API responses
Exposure of internal application metadata
Leakage of account-related or user-specific information
Increased attack surface for phishing or chained attacks
Higher impact if the same CORS policy exists on sensitive API endpoints
Severity should be assessed based on the sensitivity of the exposed response.
Low impact: Public or non-sensitive data Medium impact: Internal metadata or account-related information High impact: Sensitive user-specific data, tokens, private records, or confidential documents
How to Prevent CORS Misconfiguration
The fix is simple: do not allow every website to read API responses.
Recommended prevention steps include:
Remove wildcard CORS from sensitive API routes.
Use a strict allowlist of trusted frontend origins.
Validate the Origin header on the server side.
Never reflect arbitrary origins without validation.
Avoid combining permissive origins with credentials.
Review API gateways, shared middleware, and backend services for repeated CORS patterns.
Add automated security tests that flag wildcard CORS on non-public endpoints.
A safer configuration:
Access-Control-Allow-Origin: https://app.example.com
Vary: OriginIf multiple trusted origins are required, the server should check the incoming origin against an allowlist and only return the matched trusted origin.
CORS Misconfiguration FAQ
What is CORS misconfiguration?
CORS misconfiguration is a security issue where a server allows untrusted origins to read API responses through the browser. This can expose sensitive data if the affected endpoint returns private or user-specific information.
Is Access-Control-Allow-Origin: * always a vulnerability?
No. Access-Control-Allow-Origin: * is not always a vulnerability. It may be acceptable for public resources. However, it becomes risky when used on API endpoints that return non-public, internal, or sensitive data.
Can CORS misconfiguration lead to data leakage?
Yes. If an API endpoint returns sensitive data and allows untrusted origins to read the response, CORS misconfiguration can lead to data leakage.
What is the best way to fix CORS misconfiguration?
The best way to fix CORS misconfiguration is to remove wildcard access from sensitive endpoints and use a strict allowlist of trusted frontend origins.
How should the severity of CORS misconfiguration be decided?
The severity should be based on the data exposed. Public data may result in low severity, while user-specific information, tokens, documents, or confidential records may increase the severity.
Key Takeaway
Access-Control-Allow-Origin: * is not always dangerous by itself.
But it becomes risky when it appears on API endpoints that return non-public data.
The browser follows what the server says. If the server says every origin is trusted, the browser may allow any website to read the response.
That is why the wildcard was too friendly.
Comments