What a CORS misconfiguration vulnerability actually allows attackers to do

A CORS misconfiguration vulnerability allows a website you do not control to read responses from your application through a visitor's browser. CORS is "a browser mechanism which enables controlled access to resources located outside of a given domain", so it loosens the same-origin policy on purpose.^[3] When the policy is poorly configured, it loosens it further than you meant, and that opens the door to cross-domain attacks.^[3]

The attack runs like this. A victim visits a page the attacker controls. Script on that page tells the victim's browser to request a URL on your server. If your CORS policy treats the attacker's origin as trusted, the browser hands the response back to the attacker's script, which can forward it anywhere.^[1]

Two limits matter when you judge a finding:

• It is read access through the victim's browser. The attacker's own machine never talks to your server with the victim's identity, and nothing on the server itself is compromised.
• The victim has to load the attacker's page for anything to happen.

A CORS misconfiguration is also not CSRF and not XSS, although it gets confused with both. CSRF makes a browser send a request the user did not intend, without the attacker seeing the reply. XSS runs the attacker's script inside your own origin. A CORS flaw is about another origin being allowed to read your responses. The three can be chained for more impact, but fixing one does not fix the others.

Most CORS findings come down to one of three mistakes: reflecting any origin, validating origins with a sloppy allowlist check, or trusting the null origin.^[3] Each one defeats the Access-Control-Allow-Origin check in a different way, but the result is the same. A page the attacker chose passes as a trusted origin.

Reflection is the one you will meet most. PortSwigger Research found that "many applications make no attempt to validate the origin before reflecting it" and called this "the single most common CORS vulnerability".^[1]

Allowlists fail more quietly. PortSwigger notes that mistakes often arise when implementing CORS origin whitelists.^[3] In one case from its research, a site trusted all origins that ended in advisor.com, including definitelynotadvisor.com.^[1] The developer wrote a check that looked strict and was not.

The null origin usually arrives by accident. Some applications whitelist it to support local development.^[3] A setting added for testing on a laptop is easy to forget before launch.

If you want to know which of these patterns applies to you, see how to check your own site for a CORS misconfiguration.

A permissive origin policy becomes serious when the server also allows credentials. With Access-Control-Allow-Credentials set to true, the browser attaches the victim's cookies to the cross-origin request and still lets the calling page read the response. The attacker's script then sees what the logged-in victim sees: account details, private records, tokens returned by an API.

Without credentials, the request goes out anonymously. The attacker reads only what your server would hand to any stranger, which is usually far less interesting. That is the first question to ask about any CORS finding: does the response change when the user is logged in, and does the policy let that logged-in response cross origins?

PortSwigger's research shows what the bad case looks like. On a bitcoin exchange, "using a sequence of CORS requests, it was possible to steal encrypted backups of users' wallets".^[1] No single request did the damage. The attacker chained several authenticated reads until they reached data worth taking.

CVE-2024-8183 is a public, already-disclosed example. A CORS misconfiguration in prefecthq/prefect version 2.20.2 allowed unauthorized domains to access sensitive data, and the record says it can lead to unauthorized access to the database.^[2]

Treat that as one data point, not a rule. The CVE earned its rating because of what sat behind the permissive policy. The same header on an endpoint that serves public content would expose nothing of value. No fixed score applies to every CORS misconfiguration, so each finding has to be scored on the data and privileges it actually exposes. Our post on how a CORS misconfiguration CVSS score is decided walks through that scoring.

The same CORS bug can show up under different CWE numbers and different OWASP categories, depending on which tool or CVE assigner labeled it. That is a labeling difference, not a sign that you have two separate problems.

CWE-942, Permissive Cross-domain Security Policy with Untrusted Domains, fits a policy that trusts too many origins. MITRE describes these policies as mechanisms that "define a list of domains from which a client is allowed to make cross-domain requests", and says an attacker can exploit the weakness to transfer private information from the victim's machine to the attacker.^[4]

You will also see CWE-346, Origin Validation Error, on findings and CVE records where the root cause is a failure to validate the Origin header itself. Neither is the one correct answer. Pick the one that matches the root cause in your code and move on.

OWASP placement varies in the same way. Some sources file CORS misconfiguration under Security Misconfiguration, and some scanners report it under Broken Access Control. Both readings are defensible: the cause is a configuration mistake, and the effect is access that should have been denied.

The label does not change the fix. For that, see the fixes for each common CORS misconfiguration mistake.

A CORS misconfiguration is worth reporting when you can show that it exposes something sensitive. Impact decides how a program rates it, not the header on its own. The bitcoin exchange case mattered because wallet backups could be stolen, not because an origin was being reflected.^[1]

A reflected origin on an endpoint that only returns public content gives a triager little to act on. Before you submit, confirm three things:

1. The policy accepts an origin you control.
2. The response contains data tied to a logged-in user.
3. Your proof of concept reads that data from another origin in a real browser.

Then say plainly what was exposed and to whom. Test only targets you own or that a program has put in scope.

If the application is your own, an automated check is a starting point. For an app that handles sensitive data, a qualified security professional should review it as well.