CORS Checker

Understanding Cross-Origin Resource Sharing (CORS) Policy

Cross-Origin Resource Sharing (CORS) is a security mechanism implemented by web browsers to restrict how resources on a web page can be requested from another domain. When a browser script attempts to initiate a cross-origin request, the browser evaluates the server's HTTP response headers to determine if the action is permitted.

The CORS Checker tool evaluates whether a web browser would allow a specific cross-origin request based on the HTTP response headers you provide and the details of your request. Front-end developers, back-end developers, API platform developers, operations developers, and anyone trying to understand if browser code can read a specific response can use this tool to verify their configurations. It is also useful for checking if an OPTIONS reply approves a later method and its requested header names.

The tool operates entirely locally. Your headers and request details stay in your browser, and nothing is uploaded to or saved by BroBroGo.

The Role of Access-Control-Allow-Origin

The Access-Control-Allow-Origin header is the primary mechanism used by servers to declare which origins are permitted to read the response.

When evaluating this header, the tool checks for several conditions:

• Exact Match: If the header matches the requesting origin, the tool reports: "Access-Control-Allow-Origin exactly matches ‹origin›."
• Wildcard Match: If the header is set to * and credentials are not included, it reports: "Access-Control-Allow-Origin allows any origin for this request."
• Missing Header: If the header is absent, the request is blocked with the reason: "Access-Control-Allow-Origin is missing."
• Mismatch: If the header value does not match the requesting origin, the tool reports: "Access-Control-Allow-Origin is ‹actual›, not ‹expected›."
• Invalid Values: If the header contains multiple values or is comma-separated, it is considered invalid, resulting in: "Access-Control-Allow-Origin has an invalid value: ‹value›."

Distinguishing Actual and Preflight Responses

CORS distinguishes between two types of checks depending on the nature of the HTTP request:

1. Actual Response: This check determines whether browser code is allowed to read the body of a completed response.
2. Preflight Response: For requests that could affect server data or use non-standard headers, browsers automatically send an initial OPTIONS request. This preflight check must return a successful 2xx status code to approve the subsequent actual request.

When checking a preflight response, including the HTTP status line is necessary. If the status line is present and successful, the tool reports: "The preflight status ‹status› is successful." If the status is outside the 2xx range, it reports: "The preflight status ‹status› is not a successful 2xx status." If no status line is pasted, the preflight status check is marked as indeterminate, reporting: "No HTTP status line was pasted, so the required 2xx preflight status cannot be checked."

How Methods and Headers Function in Preflight Requests

During a preflight check, the browser verifies whether the target HTTP method and custom headers are permitted by the server.

Method Validation

If the requested method is a CORS-safelisted method, it does not need to be explicitly declared by the server. The tool reports: "‹method› is a CORS-safelisted method and does not need to appear in Access-Control-Allow-Methods." For other methods, the server must explicitly permit them, resulting in: "The preflight permits ‹method›." Otherwise, the request is blocked with: "Access-Control-Allow-Methods does not permit ‹method›."

Header Validation

If no custom headers are requested, the tool reports: "No requested header names need preflight approval." When headers are requested, they must be approved by the server's Access-Control-Allow-Headers header. If approved, the tool reports: "The preflight permits the requested header names: ‹headers›." If they are not permitted, it reports: "Access-Control-Allow-Headers does not permit: ‹headers›."

The Impact of Credentials on CORS Policy

When a request includes credentials, such as cookies or HTTP authentication, the browser enforces stricter security rules:

• No Wildcards for Origins: The Access-Control-Allow-Origin header cannot be *. If a wildcard is used with credentials, the tool blocks the request, stating: "Access-Control-Allow-Origin cannot be * when credentials are included."
• Loss of Wildcard Meaning: Wildcards (*) for allowed methods and allowed headers lose their wildcard meaning and are treated as literal asterisks when credentials are included.
• Explicit Credentials Header: The server must return Access-Control-Allow-Credentials: true. If this header is present and set to true, the tool reports: "Access-Control-Allow-Credentials is exactly true." If it is missing or not set to true, the request fails with: "A credentialed request needs Access-Control-Allow-Credentials: true."
• Uncredentialed Requests: If credentials are not included, the credentials header does not affect the evaluation, and the tool reports: "Credentials are not included, so Access-Control-Allow-Credentials does not affect this decision."

Handling the Authorization Header

The Authorization header is subject to a unique restriction under CORS rules. Even if a server attempts to allow all headers using a wildcard (Access-Control-Allow-Headers: *), this wildcard does not cover the Authorization header.

The Authorization header must always be explicitly listed by name in the Access-Control-Allow-Headers field. If it is not explicitly listed, the tool blocks the request and reports: "Authorization must be listed explicitly; Access-Control-Allow-Headers: * does not cover it." For other headers in a request without credentials, the wildcard remains valid, reporting: "Access-Control-Allow-Headers: * covers these names for a request without credentials: ‹headers›."

Tool Inputs and Validation Rules

To perform a check, you must configure the following inputs within the tool:

The tool validates these inputs and will display specific errors if the inputs are malformed, such as "Line ‹line› is not a valid HTTP header or status line." or "Enter an origin with only a scheme, host and optional port, such as https://app.example.com." If any input issues exist, the tool displays: "Fix the highlighted input and try again."

Frequently Asked Questions

Should I paste the actual response or the preflight response?

Use Actual response to check whether browser code can read one response. Use Preflight response for the OPTIONS reply that approves a later method and its requested header names.

Why can a wildcard fail with credentials?

When cookies or HTTP authentication are included, the allowed origin must match the requesting origin exactly. Wildcards for allowed methods and headers also lose their wildcard meaning.

Does a passing result prove the live request will work?

No. This result covers only the pasted response and the request details entered here. Redirects, cached responses, changing server rules, browser extensions and the actual response after a preflight can still change the outcome.

Does this tool contact my server to verify the CORS policy?

No. The tool only checks the provided response headers and request details; it does not contact a server, read URLs, set cookies, check DNS/TLS, or modify server configurations.