September 24, 2026
Understanding CORS Misconfigurations: When Trusting the Browser Goes Wrong
Introduction to CORS
By Molapo Manuel
5 min read
Introduction to CORS
CORS (Cross-Origin Resource Sharing) is a browser mechanism that enables controlled access to resources located outside a given origin.
Common CORS headers
CORS aim is to extend the flexibility of the Same-Origin Policy (SOP), allowing web applications to communicate across different origins under specific conditions.
If this is your first time hearing about the Same-Origin Policy, don't worry.
I got you.
What Is the Same-Origin Policy (SOP)?
The Same-Origin Policy is a browser security mechanism that restricts how a web page from one origin can interact with resources belonging to another origin.
An origin consists of three components:
- Scheme (HTTP or HTTPS)
- Hostname (example.com)
- Port (80, 443, 8080, etc.)
For two URLs to be considered the same origin, these components must match.
For example:
Although both URLs use the same hostname, they have different ports. Therefore, they are considered different origins.
Similarly:
These URLs use different schemes, meaning they are also different origins.
The Same-Origin Policy prevents JavaScript running on one origin from freely reading sensitive resources belonging to another origin.
However, modern web applications often need to communicate across origins. This is where CORS comes into play.
What Is CORS, and How Does It Work?
CORS allows a server to specify which external origins are permitted to access its resources through browser-based requests.
For example, suppose a company operates two applications:
The frontend application may need to retrieve user data from the API.
The API server can respond with:
Access-Control-Allow-Origin: ``[https://app.example.com](https://app.example.com)
This tells the browser that JavaScript running on the specified origin is permitted to read the response, subject to other applicable browser security rules.
CORS does not eliminate the Same-Origin Policy. Instead, it provides a controlled mechanism for relaxing certain cross-origin restrictions.
But what happens when developers implement CORS incorrectly?
This is where things become interesting for bug hunters.
Server-Generated ACAO Header From a Client-Specified Origin
Some applications need to support multiple external domains. Maintaining a list of trusted origins can require ongoing effort, so developers may implement dynamic origin handling.
Instead of validating the requesting origin, the server simply reflects whatever value the client provides in the Origin header.
Consider the following request:
GET /api/account HTTP/1.1
Host: vulnerable-website.com
Origin: ``[https://attacker.example](https://attacker.example)
The server responds:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: ``[https://attacker.example](https://attacker.example)
Access-Control-Allow-Credentials: true
The Access-Control-Allow-Origin (ACAO) header tells the browser which origin is permitted to read the response.
The Access-Control-Allow-Credentials: true header indicates that the server permits credentialed cross-origin requests.
If the victim is authenticated to the vulnerable application, their browser may include the relevant session cookie in a cross-origin request when the request's credentials mode and cookie policies permit it.
If the server reflects an arbitrary origin and allows credentials, an attacker-controlled website may be able to make authenticated requests and read sensitive responses through JavaScript.
For example, the response might contain private account information, API data, or other sensitive information.
The critical issue is not simply that the server reflects the Origin header. It is that the server trusts an unvalidated origin and allows it to read sensitive, potentially authenticated resources.
Errors in CORS Origin Whitelists
Not every application blindly reflects arbitrary origins.Some developers implement a whitelist containing trusted domains.
For example:
When a request arrives, the server checks whether the supplied origin appears in the whitelist. If it does, the server returns the corresponding ACAO header.
This approach can be secure when implemented correctly.
However, mistakes in origin validation can introduce security vulnerabilities.
1. Improper Suffix Validation
Suppose a developer intends to allow only domains belonging to:
normal-website.com
However, the application validates origins using a simple suffix-matching operation.
An attacker-controlled domain such as:
https://hackersnormal-website.com
could potentially pass a poorly implemented check because its hostname ends with the trusted domain string.
The application might then return:
Access-Control-Allow-Origin: ``[https://hackersnormal-website.com](https://hackersnormal-website.com)
The attacker-controlled origin could receive access even though it is not a legitimate subdomain of the trusted organization.
2. Improper Prefix Validation
A similar problem can occur when applications validate origins using prefix matching.
Suppose the application checks whether an origin begins with:
An attacker-controlled domain such as:
https://normal-website.com.attacker.example
could potentially pass this check.
Although the origin begins with the trusted string, the actual hostname belongs to a different domain.
These examples demonstrate why simple string matching is insufficient for validating origins.
A secure implementation should parse the origin and compare its scheme, hostname, and port against explicitly trusted origins.
The Whitelisted Null Origin
Another interesting CORS misconfiguration involves the null origin.
The Origin header can contain the value:
Origin: null
Browsers may serialize an origin as null in certain situations, including sandboxed documents and some requests originating from local files.
Some applications mistakenly include null in their trusted-origin configuration.
For example, a server may respond with:
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true
If an attacker can cause a browser to make a credentialed request from a context with a null origin, and the target permits that origin, sensitive response data may become accessible to attacker-controlled JavaScript.
The security impact depends on the browser context, cookie restrictions, endpoint behavior, and whether the response contains sensitive information.
Therefore, null origin handling is worth investigating during an authorized CORS assessment.
How Bug Hunters Can Test for CORS Misconfigurations and get dollars
When testing CORS, the objective is not merely to identify an unusual response header.
The objective is to determine whether an untrusted origin can access sensitive information that should be restricted to trusted origins.
A practical testing workflow includes:
- Identify sensitive API endpoints or resources.
- Send a request containing a controlled
Originheader. - Observe whether the server reflects the supplied origin in the ACAO header.
- Check whether
Access-Control-Allow-Credentials: trueis returned. - Test whether the origin validation can be bypassed through malformed or attacker-controlled domains.
- Determine whether a browser can actually read the response under the relevant credential and CORS conditions.
- Document the security impact using a controlled proof of concept.
For example, an authorized test request might contain:
Origin: ``[https://attacker.example](https://attacker.example)
If the server responds with:
Access-Control-Allow-Origin: ``[https://attacker.example](https://attacker.example)
that is a signal worth investigating.
However, reflection alone does not automatically establish a security vulnerability.
The finding becomes more significant when an untrusted origin can read sensitive data, particularly through authenticated browser requests.
Conclusion
CORS is an important browser security mechanism that allows web applications to communicate across different origins while maintaining controlled access to resources.
The Same-Origin Policy establishes the baseline restrictions, while CORS allows servers to selectively relax those restrictions.
However, when developers implement origin validation incorrectly, they may unintentionally expose sensitive resources to untrusted websites.
For bug hunters, understanding CORS is not just about knowing which headers to inspect. It is about understanding how browser security, server-side trust, authentication, and sensitive data interact.
Remember: A CORS misconfiguration is not just a header problem. It becomes a security issue when an untrusted origin gains access to data it should never be able to read.