Any website is allowed to read this site's responses
What this check looks for
The server told a website we invented that it may read this page's contents. It will tell any website the same thing. Cookies are not attached, so what another site can read is what an anonymous visitor sees.
Why it matters
Two things are true at once. Anything on this endpoint that is not genuinely public is now readable by any page on the internet, from the visitor's own network — which reaches internal-only responses a scanner cannot. And the day anyone adds credentials to this policy, it becomes a critical account-data leak with no further change.
When the check passes, your report says: “Cross-origin reads are limited to origins you named”.
What it costs your score
When this check fails it removes 18 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
- high
- Default confidence
- confirmed
- Status when triggered
- warn
- Deduction
- 18 points
- Family cap
- web-security.cors · 35
- Category
- Web security
- Module
- Web cors
- Fix owned by
- user
- In the ruleset since
- 2026.09
How to fix it
Replace the reflection with a fixed allow-list, or use a plain wildcard if the data really is public.
A reflection allows every site today and becomes an account-data leak the day credentials are added.
Decide what this endpoint returns. If it is genuinely public — a public API, a font, a CDN asset — say so explicitly with
Access-Control-Allow-Origin: *and no credentials, which is honest and cacheable.If it is not public, list the exact origins that need it and compare the request's
Originagainst that fixed set with an exact equality test.Return the matched origin on a match and no CORS headers otherwise; never echo the header value you were given.
Add
Vary: Originto every response so a shared cache cannot mix the two answers up.If nothing cross-origin uses this endpoint, remove the CORS headers altogether — the default of no CORS is the correct configuration, not a gap.
How to confirm it worked
curl -sSI -H 'Origin: https://not-your-site.example' https://‹host›/ | grep -i '^access-control-allow-origin:' — expect no output
curl -sSI https://‹host›/ | grep -i '^vary:' — expect Origin to be listed
Access-Control-Allow-Origin: https://app.example.com # only when the request Origin equals this exact value
Vary: OriginA 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
# 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;
}
}
}<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>@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 204const 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();
});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
maphas to be at http scope — nginx has no allow-list construct insidelocation, and building one out ofifthere is the source of most broken nginx CORS configurations. nginx skips anadd_headerwhose variable is empty, so an unmatched origin simply receives no CORS headers.alwaysis required or the headers vanish on error responses and on the 204 preflight. Remember that anyadd_headerinside alocationdiscards everyadd_headerinherited from the server block, so keep the whole set together.Shown because the response identified Apache.
SetEnvIfplusenv=is the mechanism —Header sethas no conditional form of its own, and anchoring the regex with^…$is what stopshttps://app.example.com.attacker.examplematching. 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
Setmembership 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/endsWithtest —https://app.example.com.attacker.exampleends 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› and got back Access-Control-Allow-Origin: ‹allow origin›. No Access-Control-Allow-Credentials: true was present. ‹detail›
The baseline request, sent with no Origin header, returned no Access-Control-Allow-Origin at all, and the preflight was echoed a second, different invented origin — so this is a reflection rather than an allow-list entry that happens to match.
What this does *not* mean: the browser will not attach the visitor's cookies, so a cross-origin reader sees the anonymous version of the response, not the logged-in one. What it does mean is worth stating plainly rather than dismissing. The reader is the visitor's browser, so the request comes from inside their network and carries their IP address — which reaches responses that vary by network position, by internal DNS, or by an IP allow-list. And a reflection is a policy written without an allow-list: the moment credentials are switched on, by a framework upgrade or by someone making a login flow work, this becomes web.cors.origin-reflected-with-credentials with no other change.
Detected server: ‹detected server›.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.
Other web cors checks
- The CORS policy accepts any request header from any origin
- The Access-Control-Allow-Origin value is not a valid origin
- The CORS policy grants broad methods on an unrestricted origin
- The null origin is on the CORS allow-list
- Any website can read authenticated responses from this site
- Preflight results are not cached
- The CORS response varies by origin but is not marked Vary: Origin
- Resources are shared with every origin, without credentials
- The CORS policy pairs a wildcard origin with credentials