Search DevFox

Search tools and pages.

CORS Tester

Send a real OPTIONS preflight and the actual request from a server proxy and inspect the per-rule CORS verdict for any origin

Loading tool...

What is CORS Tester

Written by Giorgos Kostas. Last reviewed:

CORS Tester runs a server-side probe instead of a browser fetch, so you can simulate any `Origin`, custom headers, and credentialed mode without configuring a temporary site to host the test.

The tool sends an `OPTIONS` preflight first, then the actual verb you specified, and renders both responses side-by-side with a per-rule verdict for `Access-Control-Allow-Origin`, `Allow-Methods`, `Allow-Headers`, `Allow-Credentials`, and `Max-Age`.

Why use it

  • Reproduce a 'CORS error' that a frontend team saw without spinning up the actual frontend.
  • Confirm that a backend Allow-Origin matches the exact origin you'll deploy to (subdomain, port, scheme).
  • Check whether credentials mode is configured correctly before shipping a cookie-based auth flow.
  • Audit Allow-Headers for a complex preflight (custom auth header, content-type, observability headers).
  • Ship a public `share` URL that shows colleagues exactly what the server returned.

Features

  • Real OPTIONS preflight + actual request from a server proxy
  • Per-rule verdict (Allow-Origin, Methods, Headers, Credentials)
  • Custom request headers + with-credentials toggle
  • Side-by-side preflight + actual response panels
  • Shareable result: copy the report as Markdown

How to use CORS Tester

  1. Enter target URL + method. Pick GET / POST / PUT / DELETE / PATCH and the resource URL.
  2. Set the test origin. This is the origin the server will see in the `Origin` header — it can differ from your own.
  3. Add custom headers. Anything that isn't safe-listed (e.g. `authorization`, `x-request-id`) triggers preflight — list it explicitly.
  4. Run the test. The proxy sends OPTIONS first, then the real request, and renders both responses with per-rule verdicts.

Example (before/after)

Request

POST https://api.example.com/orders
Origin: https://app.staging.example.com
Headers: content-type, x-request-id
Credentials: include

Verdict

Preflight (OPTIONS): 204
  Allow-Origin    ✓ matches request origin
  Allow-Methods   ✓ POST included
  Allow-Headers   ✗ missing 'x-request-id'
Actual (POST):    blocked by browser due to preflight failure

Common errors

Allow-Origin returns '*' but credentials are required

Browsers reject `Access-Control-Allow-Origin: *` whenever credentials mode is `include`.

Fix: Echo the request `Origin` back literally and pair it with `Access-Control-Allow-Credentials: true`.

Preflight succeeds but actual request fails

The actual verb may also need to set Allow-Origin; preflight covers OPTIONS only.

Fix: Apply your CORS middleware to all responses, not just to OPTIONS handlers.

Allow-Headers omits a header the browser sends

Custom headers (auth, observability) trigger preflight; Allow-Headers must include every one of them.

Fix: List headers explicitly (case-insensitive). Wildcards `*` were only standardised in CORS 2024 and aren't supported with credentials.

FAQ

How is this different from the existing CORS Origin Checker?

The Origin Checker is passive: you paste an `Access-Control-Allow-Origin` value plus a list of origins and it tells you whether the rule would match. The CORS Tester actually fires the OPTIONS preflight and the real request from a server proxy and inspects every header the origin server returns.

Will the request hit my server with a real browser fingerprint?

No — requests originate from our Node server, so the User-Agent says so and the IP is not the user's. Use the verdict to verify CORS configuration; load-test from real browsers separately.

Can I test localhost?

No — the proxy runs in the cloud and can't reach `localhost`/`127.0.0.1`/private IPs. Tunnel locally with ngrok or cloudflared and point the tester at the public URL.

Why don't you just use a browser fetch from this page?

Because the browser would block any cross-origin failure before showing it to you. By using a server proxy we can read the raw response headers — including the ones browsers hide (`Access-Control-Allow-Origin: null`, missing headers entirely) — and explain exactly why the browser would reject the request.

Are credentials supported?

Toggle 'with credentials' and the tester sends a representative cookie + checks that the response carries `Access-Control-Allow-Credentials: true` AND a non-wildcard `Allow-Origin`. The actual cookie value is generic — we don't transmit any cookies you might have on this site.

Related tools

Pair the active tester with the passive checker and other web-debugging tools. You can also browse the full Security & Web Hardening category for more options.

CORS Origin Checker

Passive Access-Control-Allow-Origin matcher — paste a header value plus a list of origins to confirm wildcard, scheme, and subdomain rules

HTTP Header Inspector

Paste response headers to audit HSTS, CSP, CORS, X-Powered-By disclosure, and Set-Cookie flags

CSP Policy Builder

Build a Content Security Policy header from per-directive cards with chip-style sources, presets, and a live header + meta-tag preview

URL Parser

Parse a URL into scheme, host, port, path, query parameters, fragment, and origin — fully client-side

URL Inspector

Inspect status, headers, redirects, and canonical hints for a URL

SSL Chain Inspector

Probe a host:port and render the full TLS certificate chain with subject, issuer, SAN, key, signature, fingerprints, and days-until-expiry

JWT Debugger

Decode JWTs, verify HMAC, RSA, and EC signatures (paste secret/PEM or fetch JWKS), inspect claims, and visualize the exp/nbf/iat timeline