Cross-Origin Resource Sharing (CORS) is a security mechanism that allows a web page from one origin (domain, scheme, port) to request resources from a different origin. Without CORS, browsers enforce the same-origin policy, which blocks cross-origin requests by default. CORS headers in the server response tell the browser which cross-origin requests are permitted.

What is the Vary: Origin header and why does it matter?

When a server returns a specific origin in Access-Control-Allow-Origin (not a wildcard), it should also include Vary: Origin in the response. This tells caches that the response varies based on the Origin request header. Without it, a cache might serve a response intended for origin A to origin B, which would be blocked by the browser, causing intermittent CORS failures.

CORS Header Checker - Free Online CORS Analyzer

Q: What is a preflight request?

A preflight request is an HTTP OPTIONS request that the browser sends automatically before certain cross-origin requests. It occurs when the request uses methods other than GET, HEAD, or POST, or includes custom headers, or uses a Content-Type other than application/x-www-form-urlencoded, multipart/form-data, or text/plain. The server responds with CORS headers indicating whether the actual request is allowed.

Q: Why is wildcard origin with credentials dangerous?

When Access-Control-Allow-Origin is set to * (wildcard) and Access-Control-Allow-Credentials is true, browsers will reject the request entirely. This combination is not allowed because credentials (cookies, HTTP authentication) are sensitive, and allowing any origin to send credentialed requests would be a major security vulnerability. Instead, the server must echo the specific requesting origin.

Q: How do I fix CORS errors?

CORS errors are fixed on the server, not the client. Add the appropriate Access-Control-Allow-Origin header (specific origin or *), Access-Control-Allow-Methods for non-simple methods, and Access-Control-Allow-Headers for custom headers. For credentialed requests, set Access-Control-Allow-Credentials to true and use a specific origin (not *). Ensure preflight responses include these headers and return a 2xx status code.

Paste HTTP response headers to analyze CORS configuration. Check allowed origins, methods, headers, credentials, and detect security warnings.

Understanding CORS and the Same-Origin Policy

Cross-Origin Resource Sharing (CORS) is a security mechanism built into web browsers that controls how web pages from one origin can request resources from a different origin. An origin is defined by the combination of scheme (http/https), domain, and port. The same-origin policy, enforced by all modern browsers, blocks cross-origin requests by default. This prevents malicious websites from reading sensitive data from other sites where the user might be authenticated. CORS provides a structured way for servers to declare which cross-origin requests they explicitly permit.

Without CORS, a JavaScript application running on https://myapp.com cannot make API calls to https://api.example.com. The browser blocks the response before JavaScript can access it. CORS headers in the server response tell the browser that the cross-origin request is authorized. This tool analyzes those headers to verify that CORS is configured correctly and securely.

How CORS Headers Work

When a browser makes a cross-origin request, it includes an Origin header indicating where the request originates. The server decides whether to allow the request and responds with appropriate CORS headers. The most important header is Access-Control-Allow-Origin, which specifies which origins may access the response. It can be a specific origin like https://myapp.com or the wildcard * to allow any origin.

Simple Requests vs. Preflight Requests

Browsers distinguish between simple and preflighted requests. Simple requests use GET, HEAD, or POST with standard content types and no custom headers. These are sent directly with an Origin header, and the browser checks the CORS headers in the response. Preflighted requests involve any method beyond GET/HEAD/POST, custom headers, or non-standard content types. For these, the browser first sends an OPTIONS request (the preflight) to check permissions. Only if the preflight succeeds does the browser send the actual request. The Access-Control-Max-Age header caches preflight results to avoid repeating them.

Credentials and Security Implications

By default, cross-origin requests do not include credentials (cookies, HTTP authentication, client certificates). To enable credentials, both the client must set credentials: 'include' and the server must respond with Access-Control-Allow-Credentials: true. Critically, when credentials are enabled, the wildcard * cannot be used for Access-Control-Allow-Origin. The server must echo the specific requesting origin. This restriction exists because allowing any origin to send credentialed requests would let any website act as the authenticated user.

Common CORS Errors and How to Fix Them

The most frequent CORS error is a missing Access-Control-Allow-Origin header. The fix is configuring the server to include this header in responses. Another common issue is wildcard origin with credentials, which browsers always reject. The solution is to dynamically set the origin header based on the incoming request. Missing Vary: Origin when using specific origins causes intermittent failures due to caching. Preflight failures often result from not handling OPTIONS requests on the server, especially when using custom headers or methods like PUT or DELETE. Each of these issues must be resolved server-side, as CORS cannot be bypassed from client-side code.

Security Best Practices

Never use wildcard origin (*) if your API handles sensitive data or uses cookies. Validate the Origin header against an allowlist of trusted domains. Always include Vary: Origin when dynamically setting the allowed origin. Set Access-Control-Max-Age to cache preflight results and reduce OPTIONS request overhead. Only expose headers that the client actually needs via Access-Control-Expose-Headers. Restrict allowed methods and headers to the minimum set required by your application. Regularly audit your CORS configuration as your API evolves.

Frequently Asked Questions

What is CORS?

A browser security mechanism that controls cross-origin HTTP requests. Servers use CORS headers to declare which origins, methods, and headers are permitted.

What is a preflight request?

An automatic OPTIONS request the browser sends before non-simple cross-origin requests to check if the actual request is allowed.

Why is wildcard origin with credentials dangerous?

Browsers reject this combination entirely. Credentials require a specific origin to prevent any website from acting as an authenticated user.

What does Vary: Origin do?

Tells caches that the response varies by Origin header. Without it, cached responses for one origin might be served to another, causing CORS failures.

How do I fix CORS errors?

CORS is fixed server-side. Add Access-Control-Allow-Origin, handle OPTIONS preflight requests, and ensure credentials configuration is consistent.

CORS Header Checker

Test Scenario (optional)

CORS Headers

Security Warnings

Test Result

Embed This Calculator