75 S&P 500 Companies Serve a CORS Policy That Reflects Any Origin While Allowing Credentials — 93% Have No Bounty Program

Access-Control-Allow-Origin: * combined with Access-Control-Allow-Credentials: true is a browser-spec violation that most servers should never produce — when it happens anyway, it means any website on the internet can make authenticated, cookie-carrying requests to that endpoint and read the response. We found it live on 75 companies in the S&P 500 index. 70 of them have no bounty program.

NullBlocks Research — September 2026

Eleven prior reports in this series have each picked one exposure class — subdomain takeover, GraphQL introspection, Wayback-archived legacy pages, version-matched critical CVEs, database/admin ports, expired TLS certs, reverse-WHOIS sister domains, missing HSTS, missing clickjacking defenses, exposed FTP servers, exposed legacy mail ports — and matched it against real bug-bounty coverage. Every time, the same shape holds. This report adds a twelfth data point, and it's the one most directly reachable by an attacker sitting in a victim's browser rather than on the open network: a broken CORS policy.

Methodology, up front

domrecon records the full response header set for every live HTTP(S) probe across every subdomain in the index. We isolated a specific, well-documented misconfiguration: a response that sets Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true on the same response.

This combination is not just risky — per the Fetch spec and every major browser's CORS implementation, a literal wildcard Access-Control-Allow-Origin: * is supposed to be incompatible with credentialed requests; browsers are meant to reject the credentialed response outright. In practice, plenty of API gateways, reverse proxies, and hand-rolled CORS middleware don't send a literal * in this case — they dynamically reflect whatever Origin header the browser sent back as the allowed origin, while still asserting Access-Control-Allow-Credentials: true. Our probe records the header pair as returned; a * observed alongside Allow-Credentials: true in our data is that class of misconfigured, origin-reflecting middleware — the resulting behavior is a session-cookie- carrying cross-origin request from literally any site being both permitted and readable by the requesting page. This is a checklist item in every CORS security guide including OWASP's, and is one of the most reliable ways to turn a single XSS or malicious ad on an unrelated site into full account takeover against an authenticated API.

We did not attempt to exploit any of these endpoints, forge a request, or access authenticated data. This is a passive HTTP response-header observation only, the same free-tier scan any domrecon user gets by entering a domain.

1. 75 of 546 companies (13.7%) serve this exact misconfiguration on at least one live host

That's across 792 individual response findings — some companies show it on a single API endpoint, others across dozens of subdomains:

That spread — industrial manufacturers, insurers, utilities, media, and a top-tier telecom all showing the same header pattern — says this isn't one framework's default misconfiguration. It's a pattern that keeps getting reintroduced independently across very different tech stacks.

2. 70 of those 75 (93.3%) have zero matched HackerOne bounty coverage

Consistent with every prior report in this series: companies serving a real, exploitable browser-security misconfiguration have almost no formal channel for a researcher who finds it to report it. All ten companies listed above by host count have zero matched HackerOne program coverage in our data — including Ford and Verizon, both large enough to plausibly run mature security programs elsewhere that simply aren't visible through HackerOne.

3. What this does and doesn't mean

An observed Access-Control-Allow-Origin: * + Access-Control-Allow- Credentials: true pair is not, by itself, proof of a working exploit — some browsers will refuse to honor a literal wildcard in this position regardless of what the server sends, and the endpoint in question might not carry sensitive session state at all. What it is proof of: a spec-violating or origin-reflecting CORS configuration sitting on production infrastructure, on a company with no visible channel to receive a report if a researcher does turn it into a working cross-origin account takeover. That's the same structural gap every report in this series has found — the coverage problem is broader than any single technique, and this one sits closer to "browser exploit primitive" than most of what we've published so far.

Why this matters if you do attack-surface work for a living

If you're a bug-bounty hunter, a CORS misconfiguration paired with authenticated cookies is one of the highest-signal, fastest-to-verify bugs in the whole OWASP catalog — a five-minute curl with a spoofed Origin header tells you immediately whether it's real. If you're running a security practice for clients, knowing which of their subdomains reflect arbitrary origins with credentials enabled — continuously, not as a one-off audit — is exactly the kind of finding that's easy to miss between engagements and expensive to have missed. That's the gap NullBlocks/DomRecon is built to keep closing automatically — this report used data already sitting in the platform, not a one-off scan built for a blog post.