CORS Configuration Checker

What this CORS checker tests

Same-origin policy is the browser's default: JavaScript on one site cannot read responses from another. CORS is how a server opts out of that default, origin by origin, using Access-Control-* response headers. Getting it right means naming exactly which origins may read which responses; getting it wrong means quietly letting any website do it. This tool sends three deliberately unusual requests and reports exactly what came back for each, so you can see the actual behaviour rather than guess at it from a single header dump.

Reflecting an arbitrary origin

We send a normal GET request with Origin: https://averto-cors-test.example — a domain we made up, which cannot be on any real allowlist. Some servers, instead of checking the incoming Origin against a list, just copy it straight into Access-Control-Allow-Origin. If that made-up origin comes straight back, the server isn't doing an allowlist check at all. On its own that lets any site read non-authenticated responses on a visitor's behalf. Combined with Access-Control-Allow-Credentials: true, it means any website can send a credentialed request — cookies and session included — from a victim's browser and read the authenticated response. That is the single most serious finding this tool can produce, because it effectively removes the origin check that credentialed CORS depends on.

The wildcard, in context

Access-Control-Allow-Origin: * looks similar to a reflected origin but means something different: literally every origin is allowed, not just the one that happened to ask. For a public, unauthenticated API this is fine and normal — we mark it informational rather than flagging it, because crying wolf on a correct configuration trains people to ignore the report. It only becomes a real problem paired with credentials, and browsers already refuse to honour that specific combination — though seeing it still signals a CORS layer that isn't distinguishing public from private responses.

Origin: null

We also send a request with the literal Origin: null. This isn't a made-up edge case — browsers send it from sandboxed iframes (<iframe sandbox>), from pages opened directly as local files, and from some redirect chains. If a server accepts null as a trusted origin, an attacker can trivially construct a page that produces exactly this header, making it one of the easier CORS misconfigurations to actually exploit.

The preflight: methods and headers

For requests that aren't "simple" — a PUT, or one carrying an Authorization header — browsers send an OPTIONS preflight first and only proceed if the server explicitly allows it. We send exactly that: Access-Control-Request-Method: PUT and Access-Control-Request-Headers: authorization, from our made-up origin. If the response allows our fake origin and also lists PUT, DELETE or PATCH in Access-Control-Allow-Methods, that's not just a read exposure — it means state-changing calls are reachable cross-origin too. A wildcard or reflected value in Access-Control-Allow-Headers is what would let a cross-origin caller actually attach an Authorization header to that request in the first place.

No CORS headers at all

Most sites should see this, and it's the pass condition, not a gap: if none of the three probes get any Access-Control-* header back, the browser's default same-origin policy is doing its job untouched. You only need CORS headers at all if you deliberately serve another origin — an API for a separate frontend, a public widget, a partner integration.

A correct, scoped configuration

For an API that legitimately needs to serve one or two specific frontends with credentials:

// pseudocode — check the Origin against a real allowlist server-side
const ALLOWED = ['https://app.example.com', 'https://admin.example.com'];
if (ALLOWED.includes(requestOrigin)) {
  Access-Control-Allow-Origin: <the matched origin, not *>
  Access-Control-Allow-Credentials: true
  Vary: Origin
}

The Vary: Origin line matters as much as the check itself — without it, a caching layer can serve one visitor's allowed-origin response to a different visitor whose origin should have been rejected.

How the grade is calculated

Every check starts at 100 and deducts based on severity — a reflected origin with credentials costs far more than a long Access-Control-Max-Age. Scores of 90+ earn an A, 75 a B, 55 a C, 35 a D, and below that an F. Treat the grade as a summary: one critical finding here matters more than several informational ones, so read past the letter.