CORS Headers Checker
Check how a URL handles CORS — see its Access-Control-Allow-* headers from a real cross-origin request and preflight, and get flagged on wildcard, origin-reflection, and credential risks. Free.
💡 What this checks
- Whether a URL shares its responses with other websites via CORS.
- The
Access-Control-Allow-*headers from a simple request and a preflight. - Risky configs: a wildcard
*, an origin that reflects any site, or credentials shared too widely.
Free CORS Headers Checker
Check how a URL or API endpoint handles Cross-Origin Resource Sharing (CORS). Enter a URL to see its Access-Control-Allow-* headers from a real cross-origin request and preflight, plus a graded report that flags risky configurations like wildcards, origin reflection, and over-shared credentials. Free, no sign-up.
What is CORS?
Cross-Origin Resource Sharing (CORS) is the browser mechanism that decides whether a web page on one origin may read a response from another origin. By default, the same-origin policy blocks this. A server opts in by sending Access-Control-Allow-* headers. Getting these right is important: too restrictive and legitimate front-ends break, too permissive and other websites can read data they shouldn't.
How the checker works
The tool sends two requests to your URL on your behalf:
- A simple cross-origin GET carrying a test Origin header.
- A preflight OPTIONS request, like a browser sends before non-simple requests.
- It then reads the Access-Control-Allow-Origin, Allow-Credentials, Allow-Methods, Allow-Headers, Max-Age, and Expose-Headers values.
- Finally it grades the configuration and explains any risks.
The CORS headers explained
A handful of response headers control everything:
- Access-Control-Allow-Origin — which origin(s) may read the response ('*' means any).
- Access-Control-Allow-Credentials — whether cookies and credentials may be sent.
- Access-Control-Allow-Methods — which HTTP methods are permitted cross-origin.
- Access-Control-Allow-Headers — which request headers are permitted.
- Access-Control-Max-Age — how long the browser may cache the preflight result.
- Access-Control-Expose-Headers — which response headers scripts may read.
The most dangerous CORS misconfiguration
The classic vulnerability is a server that reflects whatever Origin it receives back in Access-Control-Allow-Origin and also sets Access-Control-Allow-Credentials: true. That combination lets any website make authenticated requests to your API and read the responses — including a logged-in user's private data. This checker deliberately sends an arbitrary test Origin so it can detect exactly this reflection behaviour and warn you about it.
Wildcard vs specific origins
Access-Control-Allow-Origin: * is perfectly fine for genuinely public, non-authenticated resources like a public font or open data API. It becomes a problem the moment private or authenticated data is involved. Note that browsers do not allow '*' together with credentials, so a server trying to do both is misconfigured. For anything sensitive, allowlist specific trusted origins rather than using a wildcard or reflecting the request origin.
Pro tip
Maintain an explicit allowlist of the exact origins your front-ends use, and only enable Allow-Credentials when you truly need cookies cross-origin — and never alongside a wildcard or reflected origin. Keep Allow-Methods and Allow-Headers limited to what you actually use. To review the rest of a response's headers, pair this with our HTTP Response Headers Viewer and Security Headers Checker.
FAQ
Is this CORS checker free?
What does Access-Control-Allow-Origin: * mean?
Why is reflecting the Origin dangerous?
Can I use a wildcard with credentials?
What is a preflight request?
My site shows no CORS headers — is that bad?
Does the checker change anything on my server?
Related tools
Pro tip: pair this tool with Robots.txt Exposure Checker and Cookie Security Checker for a faster SEO workflow.