SSL & Security

CORS Headers Checker

CORS Headers

Check CORS headers

Enter your domain name to check and analyze CORS headers configuration.

Tool features

Comprehensive CORS headers analysis and security assessment
4 checks

CORS Security Analysis

Comprehensive analysis of Cross-Origin Resource Sharing headers

Header Validation

Check all CORS-related headers and their security configuration

Security Assessment

Detailed security analysis and recommendations for CORS configuration

Origin Control

Verify Access-Control-Allow-Origin configuration and security

What is CORS & how it works

How browsers govern cross-origin requests

CORS (Cross-Origin Resource Sharing) is the browser security mechanism that decides whether a web page on one origin is allowed to read a response from a different origin. The server signals its policy through Access-Control-Allow-Origin and related headers; if they're missing or too permissive, browsers either block legitimate requests or expose the API to any site on the internet.

This checker fetches your endpoint, inspects the CORS response headers, and explains what they allow. It flags the two failure modes that matter most: a policy so strict it breaks your own front-end, and a wildcard * (especially combined with credentials) that leaks data to untrusted origins.

Access-Control-Allow-Origin
Lists which origins may read the response. A specific origin is safe; * allows any site.
Allow-Credentials
When true, cookies and auth headers are shared cross-origin. It must never be combined with a * origin.
Preflight (OPTIONS)
For non-simple requests the browser first sends an OPTIONS request to confirm the method and headers are allowed.

How to use this tool

Inspect a site's CORS policy in four steps
1
Enter a domain or URL
Type the endpoint whose CORS policy you want to inspect, e.g. example.com.
2
Run the CORS check
We request the resource and read back its Access-Control-* response headers.
3
Review the policy
See which origins, methods, and headers are allowed and whether credentials are shared.
4
Tighten or fix the config
Replace risky wildcards with specific origins, or add the headers your front-end needs.

Related tools

Keep debugging with tools from the same suite
5 tools
X-Frame Options Checker
Check X-Frame-Options header to prevent clickjacking attacks and iframe embedding
Secure Header Checker
Check security headers like CSP, HSTS, X-Frame-Options, and more with security scoring
OCSP Checker
Check SSL certificate revocation status using the Online Certificate Status Protocol (OCSP)
HTTP Header Checker
Analyze HTTP response headers for any website or URL with detailed header information
CORS Tester
Test Cross-Origin Resource Sharing (CORS) configuration and headers

Frequently asked questions

Common questions about CORS headers
5 Q&A

It allows any website to read the response. That's fine for truly public data, but dangerous for anything user-specific — and it cannot be combined with credentialed requests.

The server likely isn't returning an Access-Control-Allow-Origin header that matches your site's origin, or a preflight OPTIONS request is failing because the method or headers aren't allowed.

For non-simple requests (custom headers, methods like PUT/DELETE), the browser first sends an OPTIONS 'preflight' to ask the server whether the real request is permitted. The server must answer with the matching Allow-* headers.

No. If Access-Control-Allow-Credentials is true, the Access-Control-Allow-Origin must echo a specific origin, not *. Browsers reject the wildcard-plus-credentials combination.

CORS is enforced by the browser but configured on the server. You set the Access-Control-* response headers on your API or web server; the browser then decides whether to expose the response to the calling page.