CORS Tester

Server assisted Web

Check whether an API allows a specific origin, method and headers. The tool issues OPTIONS and actual requests through a safe server-side checker and explains why the browser would allow or block the call.

Privacy: Processing happens in your browser where possible. Network checks are relayed through the Mutqan backend and are not stored.

What is CORS?

CORS (Cross-Origin Resource Sharing) is the browser mechanism that decides whether a page on one origin may read a response from another. The server opts in with Access-Control-Allow-Origin and related headers; for requests with custom headers or non-simple methods the browser first sends an OPTIONS preflight. CORS protects users in browsers only — it does not restrict servers, curl or mobile apps.

The browser, not the API, enforces CORS: it sends an OPTIONS preflight, checks the answer, and only then sends the real request and checks it again.
  • Web page https://app.example.com
  • Browser
  • API api.example.com
  1. 1 From Web page To Browser: Calls the API with credentials Sends Authorization and Content-Type POST /v1/orders
  2. 2 Browser internally: Preflight needed? Yes: Authorization and a JSON Content-Type are outside the CORS-safelisted set
  3. 3 From Browser To API: Preflight With Origin plus Access-Control-Request-Method and Access-Control-Request-Headers OPTIONS /v1/orders
  4. 4 From API To Browser: Preflight response reply A status and Access-Control-Allow-* headers
  5. 5 Browser internally: Checks the preflight Needs 2xx, both headers in Allow-Headers, Allow-Credentials: true and Allow-Origin set to the exact origin, never *
  6. 6 From Browser To API: Actual request Sent only if the preflight passed, with Origin and cookies or Authorization POST /v1/orders
  7. 7 From API To Browser: Response reply With its own Access-Control-Allow-* headers
  8. 8 Browser internally: Checks the response Needs Allow-Credentials: true and Allow-Origin set to the exact origin, never *
  9. 9 From Browser To Web page: The response, or a generic error reply If any check fails, the response stays hidden from the page

Outcome: In the example the API answers Access-Control-Allow-Origin: * and leaves Authorization out of Allow-Headers, so the verdict is Blocked. Fail

Per the Fetch Standard. A GET, HEAD or POST with only CORS-safelisted headers skips steps 3 to 5; Allow-Methods matters only for other methods. The tool’s relay sends both requests, and the tool applies these checks to their headers.

How to use CORS Tester

  1. Enter the public API URL and the origin of the web app that will call it.
  2. Select the method and list the request headers the app will send (Authorization, Content-Type…).
  3. Run the test and read the verdict; the "Why" list names the exact header that would block the browser.
  4. Fix the server configuration and re-run until the verdict is Allowed.

CORS Tester features

  • Sends a preflight (OPTIONS) announcing your method and request headers, then the actual request with your chosen Origin
  • Verdict explained step by step: origin match, credentials, allowed methods and headers, preflight status, max-age
  • Detects when a preflight is required using the CORS-safelisted rules
  • Tables of preflight and actual response headers with explanations
  • Warns about wildcard-with-credentials and missing Vary: Origin

CORS Tester example

Test a credentialed POST (output shortened)

Input:

URL: https://api.example.com/v1/orders · Origin: https://app.example.com · Method: POST · Headers: Authorization, Content-Type

Output:

Result: Blocked
Preflight needed: Yes (OPTIONS) · Preflight status: 204
Access-Control-Allow-Origin is "*" but the request is credentialed; browsers reject the wildcard with credentials.
Access-Control-Allow-Headers does not list: Authorization.

Frequently asked questions about CORS Tester

When does a browser send a preflight?

For any method other than GET, HEAD or POST, and for request headers outside the CORS-safelisted set: Accept, Accept-Language, Content-Language, Content-Type only with application/x-www-form-urlencoded, multipart/form-data or text/plain, and Range only with a single bytes range. So Content-Type: application/json triggers one. The tool tells you whether your combination triggers OPTIONS; it receives header names only, so a Content-Type or Range you list is treated as a non-safelisted value. Leave it out to test a form or text/plain request.

Why is my request blocked even though Access-Control-Allow-Origin is *?

A wildcard is rejected when the request uses credentials (cookies or Authorization with credentials: "include"). Echo the exact origin, add Access-Control-Allow-Credentials: true and Vary: Origin instead.

Why does the tool call the API from a server instead of my browser?

A browser hides the blocked response, so you would only see a generic error. The relay performs the OPTIONS and actual requests with the Origin header you chose and returns the raw Access-Control-* headers so the verdict can be explained.

Can I test localhost or an internal API?

No. The relay refuses private, loopback and link-local addresses for safety. Expose the API through a tunnel (e.g. a public staging host) to test it.

Technical notes

The relay reproduces the browser algorithm from the Fetch Standard: the preflight is sent with Access-Control-Request-Method and Access-Control-Request-Headers, and the actual request with the Origin header. The server-side verdict is combined with a local re-evaluation so every reason is spelled out, including cases the relay treats as allowed but that fail for credentialed requests.

References

  • Fetch StandardWHATWGDefines CORS: preflight requests, the Access-Control-* headers and which responses a browser may expose to a page.
  • Cross-Origin Resource Sharing (CORS) — MDNMDN Web Docs (Mozilla)How CORS works in practice: simple vs. preflighted requests, credentials, and the errors browsers report.