CORS allows arbitrary origins with credentials

Scan.now sends two ordinary GET / requests over HTTPS with an Origin request header: one using an origin that cannot be yours (https://scan-now-probe.invalid) and one using the literal value null. It then reads Access-Control-Allow-Origin and Access-Control-Allow-Credentials from each response. The check fails at high severity when the arbitrary origin, or null, is echoed back and credentials are allowed. It reports a lower-severity note when the origin is reflected without the credentials flag, and when Access-Control-Allow-Origin: * is used, which browsers never combine with credentials but which still exposes any response that is protected by network position rather than cookies. Only the homepage is probed; API routes can have their own, different, CORS configuration, so treat a pass as a sample rather than a guarantee. No preflight or custom methods are sent.

The same-origin policy is what stops evil.example from reading your users' data out of your site. CORS is the mechanism for deliberately relaxing it. A server that copies whatever Origin it receives into the allow header, and adds Allow-Credentials: true, has relaxed it for everyone: any page the victim visits can issue fetch('https://your-site/account', {credentials: 'include'}) and read the response, including personal data, API keys shown in a dashboard, or the anti-CSRF token needed to make state-changing requests. The null origin is exploitable through a sandboxed iframe, which is why it is treated as equivalent. Reflecting subdomains by suffix match is a common near-miss: a single XSS or takeover on any subdomain then yields the same access. James Kettle's 2016 PortSwigger research documented these patterns on major sites and they remain a staple of bug-bounty reports. Background on the policy is in the website security hub.

Compare the incoming Origin against an explicit allowlist and echo it only on a match; never derive the value from the request by pattern. Express with the cors package:

const allowed = ['https://app.example.com', 'https://admin.example.com'];
app.use(cors({
  origin: (origin, cb) => cb(null, !origin || allowed.includes(origin)),
  credentials: true,
}));

nginx, using a map so unmatched origins get no header at all:

map $http_origin $cors_origin {
    default "";
    "https://app.example.com"   $http_origin;
    "https://admin.example.com" $http_origin;
}
server {
    add_header Access-Control-Allow-Origin $cors_origin always;
    add_header Access-Control-Allow-Credentials "true" always;
    add_header Vary "Origin" always;
}

Apache with mod_headers uses SetEnvIf Origin plus Header set Access-Control-Allow-Origin "%{ORIGIN}e" env=ORIGIN against a regex of the exact allowed hosts. Always add Vary: Origin so caches do not serve one origin's allow header to another. If the endpoint is public and needs no cookies, use * without the credentials flag. Cloudflare Transform Rules can add fixed CORS headers, but dynamic allowlists belong in the application.