CORS Response Inspect

Diagnose security headers and policies in your browser. No input is sent to a server. Use it for first-pass checks before rollout.

Status

Runs in your browser. No input is sent to a server. Use this as a first-pass diagnostic step.

How to use

Paste Access-Control-Allow-* headers and click “Parse”. It lists allowed settings (header lines/multi-line paste/full headers OK).

Notes (this tool)

  • Actual CORS behavior depends on the request and server implementation.

About this page

What does this tool do?

Split Access-Control-Allow-Origin/Methods/Headers/Credentials and show what is allowed.

Useful for diagnosing CORS failures or overly broad permissions.

Basics (CORS responses)

  • CORS permissions are expressed via response headers.
  • Access-Control-Allow-Origin is required; others depend on use case.
  • With credentials, wildcard * is not allowed.
  • What to check differs between “simple requests” and “preflight (OPTIONS)”.

Glossary (quick)

  • Origin: where the request comes from (scheme+host+port).
  • Simple request: if certain conditions are met, preflight is skipped.
  • Preflight: an OPTIONS request that asks permission before the actual request.
  • Credentials: opting into cookies/auth (browser-side opt-in).
  • Expose-Headers: explicitly expose additional response headers to JS.

Headers to check in preflight

Many CORS failures happen at the preflight (OPTIONS) stage, not the actual request.

  • Access-Control-Allow-Methods: includes the method you intend to use (GET/POST/PUT...)
  • Access-Control-Allow-Headers: includes headers you will send (e.g., Authorization)
  • Access-Control-Max-Age: cache duration for preflight results (browser-dependent caps exist)

Testing with curl (quick)

If you want a quick repro without opening a browser, simulate preflight with curl.

  • Preflight example: curl -i -X OPTIONS https://api.example/endpoint -H \"Origin: https://app.example\" -H \"Access-Control-Request-Method: POST\" -H \"Access-Control-Request-Headers: content-type, authorization\"
  • Actual request example: curl -i https://api.example/endpoint -H \"Origin: https://app.example\"

Paste the resulting Access-Control-Allow-* headers here to get a clearer summary.

Input examples

  • Access-Control-Allow-Origin: https://app.example
  • Access-Control-Allow-Methods: GET, POST
  • Access-Control-Allow-Headers: Content-Type, Authorization
  • Access-Control-Allow-Credentials: true

Common pitfalls

  • Credentials=true with Allow-Origin * (invalid)
  • Dynamic Origin response without Vary: Origin
  • Allow-Headers does not match requested headers in preflight
  • Allow-Methods is incomplete: OPTIONS passes but the actual request fails
  • Missing Expose-Headers: JS cannot read the headers you expect

Key points when using credentials (cookies/auth)

When browsers send cookies or auth, the CORS policy becomes stricter.

  • Return Access-Control-Allow-Credentials: true (only if needed).
  • Access-Control-Allow-Origin must be a concrete Origin, not *.
  • If you allow multiple origins, dynamically return a matched origin and add Vary: Origin.

On the client side (fetch), you also need an opt-in such as credentials: \"include\"; both sides must align.

Caching and Vary (prevent cache mixing)

Because CORS changes who can see a response, caches can accidentally mix responses across origins.

  • If Allow-Origin is dynamic, add Vary: Origin (effectively required).
  • For cached preflight (OPTIONS), consider Vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers.
  • A large Max-Age can delay policy changes from taking effect.

Security notes (risk of over-permission)

  • Reflecting the Origin blindly can unintentionally allow any site.
  • Overly broad Allow-Headers/Methods make unintended requests more likely to pass.
  • Be extra careful with Credentials=true (cookies increase impact).

Symptom-based checklist

  • “CORS policy” error: first verify preflight (OPTIONS) returns 2xx.
  • Only POST/PUT fails: check Allow-Methods.
  • Fails when adding Authorization: ensure Allow-Headers includes authorization.
  • Cookie fails: check Allow-Credentials=true and concrete Allow-Origin (not *).
  • JS can’t read a header: check Expose-Headers (e.g., X-Request-Id).

Debugging workflow (recommended)

  • Extract CORS headers via Response Headers Parser
  • Summarize permissions with this tool
  • Check allowlist matching with Origin Allowlist Check
  • Verify Vary: Origin using Vary Inspect
  • Origin Allowlist Check
  • Host/Authority/Origin Inspect
  • CORS Checklist
  • Response Headers Parser
  • Request Headers Parser
  • Vary Inspect

What this tool does

  • Split Access-Control-Allow-* headers
  • Check Credentials/Expose-Headers
  • Display Max-Age (preflight cache) clearly
  • Extract CORS headers from full headers

Operational notes

  • Recommended values are environment-dependent. Validate against functional requirements before applying.
  • In production, use phased rollout with report monitoring.

Referenced specs

  • RFC 6454 (Origin)
  • Fetch Standard (CORS)
  • MDN: CORS

FAQ

When can I use * for Allow-Origin?

Only when credentials are not used. It’s invalid with Credentials=true.

Is Vary: Origin required?

If you dynamically return Origin, it’s effectively required to prevent cache mixing.

Why do I see a CORS error even when HTTP is 200?

Browsers can block exposing the response to JS. Common causes are preflight (OPTIONS) failure or mismatched Allow-* headers.

When do I need Expose-Headers?

When you want JS to read custom headers (e.g., X-Request-Id). Without it, those headers won’t be accessible.

References

  1. Fetch Standard
  2. RFC 6454
  3. MDN: CORS
  4. MDN: Access-Control-Allow-Origin
  5. MDN: Access-Control-Allow-Methods
  6. MDN: Access-Control-Allow-Headers
  7. MDN: Access-Control-Allow-Credentials
  8. MDN: Access-Control-Expose-Headers
  9. MDN: Access-Control-Max-Age
  10. MDN: Vary

Page-specific case studies

This page inspects Access-Control-* response values and verifies they match browser expectations.

  • Check whether Allow-Origin is the intended exact origin.
  • Ensure Allow-Methods covers actual request methods.
  • Confirm Expose-Headers satisfies frontend requirements.

Page-specific implementation checklist

  • Unify CORS header generation between app and proxy layers.
  • Align Allow-Credentials with session design.
  • Require Vary: Origin when origin is dynamic.
  • Capture raw headers during incidents for reproducibility.

These links are generated from site_map rules in recommended diagnostic order.

  1. CORS Error Troubleshooting — Troubleshoot CORS failures by correlating browser errors with request/response headers
  2. CORS Diagnostic — Diagnose CORS decisions by comparing Origin and Allow-*
  3. Origin Allowlist Check — Match Origin values against an allowlist
  4. How to Diagnose CORS Preflight Failures — Fix preflight failures by validating OPTIONS responses, Allow-* directives, and origin rules in order
  5. How to choose CORS tools — Map preflight failures, origin mismatches, and credential conflicts to the right checks
  6. Host/Authority/Origin Inspect — Cross-check Host/:authority/Origin/Referer for mismatches
  7. CORS Checklist — Provide a step-by-step CORS verification checklist

CORS

Compare Origin and Allow-* headers to audit CORS decisions