Any website can read authenticated responses from this site

CriticalConfirmedweb.cors.origin-reflected-with-credentials

What this check looks for

We asked for this page while claiming to be a website we made up, and the server said that website is allowed to read the answer — with the visitor's cookies attached. It will say that about any website that asks.

Why it matters

Any page a logged-in visitor opens can silently read their data from your site: account details, personal information, anything an API returns, and the CSRF tokens that protect every other action. The visitor never sees it happen, and your logs show an ordinary request from a real user.

When the check passes, your report says: “Credentialed responses go only to origins you named”.

What it costs your score

When this check fails it removes 30 points from your Web security score, before the status, confidence and repeat multipliers are applied. Web security carries a weight of 8 in the overall score.

It shares the web-security.cors family ceiling of 35 points: however many findings that family produces, together they cannot remove more than that from Web security. One underlying problem showing up in several places is still one problem.

Severity: critical
Default confidence: confirmed
Status when triggered: fail
Deduction: 30 points
Family cap: web-security.cors · 35
Category: Web security
Module: Web cors
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Replace the reflection with a fixed allow-list, and grant credentials only on a match.

Echoing the requester's origin allows every website; only a fixed list allows the ones you meant.

Write down the exact origins that legitimately need cross-origin access, scheme and port included. If the answer is none, remove the CORS headers entirely rather than narrowing them.
Compare the request's Origin against that fixed set with an exact string equality test — not a prefix, suffix, includes or regex without ^ and $ anchors, each of which https://app.example.com.attacker.example defeats.
On a match, return that matched origin as Access-Control-Allow-Origin and Access-Control-Allow-Credentials: true. On anything else, return neither header — an unmatched origin gets no CORS response, not a weakened one.
Add Vary: Origin to every response, matched or not, so a cache or CDN cannot hand one origin's answer to another.
Search the codebase for the middleware option that produced the reflection — a CORS origin set to true, to a callback that returns its argument, or to the request header — and remove it.
Treat the exposure as real: anything readable cross-origin while this was live should be assumed read, and CSRF tokens issued during that window should be rotated.

How to confirm it worked

curl -sSI -H 'Origin: https://not-your-site.example' https://‹host›/ | grep -i '^access-control-allow-' — expect no output at all
curl -sSI -H 'Origin: https://app.example.com' https://‹host›/ | grep -i '^access-control-allow-origin:' — expect exactly that one allowed origin
curl -sSI https://‹host›/ | grep -i '^vary:' — expect Origin to be listed

The configuration to publish

Access-Control-Allow-Origin: https://app.example.com   # only when the request Origin equals this exact value
Access-Control-Allow-Credentials: true
Vary: Origin

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

nginx

# http scope. The map is the allow-list: an origin that is not a key here gets "".
map $http_origin $cors_origin {
	default                     "";
	"https://app.example.com"   "https://app.example.com";
	"https://admin.example.com" "https://admin.example.com";
}

# Credentials are granted only when the origin matched.
map $cors_origin $cors_credentials {
	default "";
	~.      "true";
}

server {
	location /api/ {
		add_header Access-Control-Allow-Origin      $cors_origin always;
		add_header Access-Control-Allow-Credentials $cors_credentials always;
		add_header Access-Control-Allow-Methods     "GET, POST, OPTIONS" always;
		add_header Access-Control-Allow-Headers     "Authorization, Content-Type" always;
		add_header Access-Control-Max-Age           "600" always;
		add_header Vary                             "Origin" always;

		if ($request_method = OPTIONS) {
			return 204;
		}
	}
}

Apache

<IfModule mod_headers.c>
	# The capture group is the allow-list: only these exact origins set the variable.
	SetEnvIf Origin "^(https://app\.example\.com)$"   CORS_ORIGIN=$1
	SetEnvIf Origin "^(https://admin\.example\.com)$" CORS_ORIGIN=$1

	Header always set Access-Control-Allow-Origin      "%{CORS_ORIGIN}e" env=CORS_ORIGIN
	Header always set Access-Control-Allow-Credentials "true"            env=CORS_ORIGIN
	Header always set Access-Control-Allow-Methods     "GET, POST, OPTIONS" env=CORS_ORIGIN
	Header always set Access-Control-Allow-Headers     "Authorization, Content-Type" env=CORS_ORIGIN
	Header always set Access-Control-Max-Age           "600"             env=CORS_ORIGIN

	# Unconditional: the response varies by Origin whether or not this one matched.
	Header always append Vary Origin
</IfModule>

Caddy

@allowed_origin header Origin https://app.example.com

header @allowed_origin {
	Access-Control-Allow-Origin "https://app.example.com"
	Access-Control-Allow-Credentials "true"
	Access-Control-Allow-Methods "GET, POST, OPTIONS"
	Access-Control-Allow-Headers "Authorization, Content-Type"
	Access-Control-Max-Age "600"
}

# Unconditional, so caches key on Origin even for the unmatched response.
header Vary Origin

@preflight method OPTIONS
respond @preflight 204

Express

const ALLOWED_ORIGINS = new Set([
  'https://app.example.com',
  'https://admin.example.com',
]);

app.use((req, res, next) => {
  // Set unconditionally: the answer depends on Origin even when it is refused.
  res.vary('Origin');

  const origin = req.headers.origin;
  if (origin !== undefined && ALLOWED_ORIGINS.has(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Access-Control-Allow-Credentials', 'true');
    res.setHeader('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');
    res.setHeader('Access-Control-Allow-Headers', 'Authorization, Content-Type');
    res.setHeader('Access-Control-Max-Age', '600');
  }
  if (req.method === 'OPTIONS') return res.sendStatus(204);
  next();
});

Cloudflare

Rules → Overview → Create rule → Response Header Transform Rule (path as at 2026-09), with an expression that tests the request Origin against a fixed list, e.g.
  http.request.headers["origin"][0] in {"https://app.example.com" "https://admin.example.com"}
and a matching rule that always sets Vary: Origin.

The map has to be at http scope — nginx has no allow-list construct inside location, and building one out of if there is the source of most broken nginx CORS configurations. nginx skips an add_header whose variable is empty, so an unmatched origin simply receives no CORS headers. always is required or the headers vanish on error responses and on the 204 preflight. Remember that any add_header inside a location discards every add_header inherited from the server block, so keep the whole set together.
Shown because the response identified Apache. SetEnvIf plus env= is the mechanism — Header set has no conditional form of its own, and anchoring the regex with ^…$ is what stops https://app.example.com.attacker.example matching. Put it in the virtual host: .htaccess runs too late for responses the server generates itself, including the preflight.
The header Origin <value> matcher compares the whole value, so it is an exact-match allow-list rather than a prefix test. Repeat the matcher and block for each additional origin.
The origin is written back only after the Set membership test, which is the difference between an allow-list and a reflection. Never build the set from a request value, an environment variable that is not reviewed, or a substring/endsWith test — https://app.example.com.attacker.example ends with nothing useful but starts with everything an attacker needs.
Treat this as a sketch of the approach rather than a copy-paste: the exact expression and the dynamic-value syntax differ between Cloudflare plans, and a static-value rule can only serve one origin. A Transform Rule also runs at Cloudflare's edge, so an origin that is reachable directly — by IP, or through a DNS record that is not proxied — still serves the policy measured here. Setting the allow-list at the origin covers both paths and is what we recommend.

Technical detail

We sent Origin: ‹probe origin› to ‹origin› — an origin under a name we control, which ‹host› has no reason to have on any list — and the response came back with Access-Control-Allow-Origin: ‹allow origin› and Access-Control-Allow-Credentials: true. ‹detail›

The reflection is the vulnerability, not the header. A *static* allow-list containing your own origins is a completely normal configuration and this rule does not fire on it: we know the difference because the preflight was sent with a second, different invented origin and that one was echoed too, while the baseline request carrying no Origin at all produced no Access-Control-Allow-Origin. A server that echoes whatever it is handed has, in effect, allow-listed every website on the internet.

Access-Control-Allow-Credentials: true is what converts it from an information leak into account access: it tells the browser to attach the visitor's cookies to the cross-origin request *and* to hand the response body to the calling page. Either one alone is survivable. Together they are a read primitive against every logged-in session.

The usual origin is a framework or middleware setting that takes the request origin as its allowed value, sometimes behind an option named for convenience rather than for what it does. Detected server: ‹detected server›.