Origin Allowlist Check

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 Origin and allowlist, then click “Check”. It shows match results (Origin: line/multi-line paste OK).

Notes (this tool)

  • This is a simplified matcher; actual CORS behavior depends on server implementation and config.

About this page

What does this tool do?

Check if an Origin matches your allowlist to quickly spot CORS configuration mismatches.

Useful for debugging CORS failures caused by subdomain or port mismatches.

Basics (allowlist approach)

  • Origin is scheme + host + port.
  • Allowlists should be explicit matches by default.
  • Use wildcards sparingly for safety.

Matching rules in this tool

  • Exact match: https://example.com
  • Subdomain wildcard: https://*.example.com
  • Any port: https://example.com:*
  • Null Origin: null

Scheme is required; host comparison is case-insensitive. *.example.com does not match example.com itself.

Input examples

  • Origin: https://app.example.com
  • Allowlist: https://example.com
  • Allowlist: https://*.example.com

Common pitfalls

  • Origin is not just host (scheme/port matter)
  • example.com does not match *.example.com
  • Overly broad allowlists increase security risk

Best practices (safe allowlists)

  • Prefer exact matches in production; minimize wildcards
  • Use separate domains for staging/testing
  • Use any-port ( :* ) sparingly; explicit ports are safer

How to test (measure)

You can verify Origin values by sending real requests in the browser, or by using curl with an Origin header.

  • curl -I -H \"Origin: https://app.example\" https://api.example
  • Check Access-Control-Allow-Origin in the response for a match

Troubleshooting checklist by symptom

  • CORS failing: verify Origin scheme/port matches the allowlist
  • Some origins fail: often due to subdomain/port differences
  • Unexpected origins allowed: check if wildcard scope is too broad

Debugging workflow (recommended)

  • Extract Origin via Request Headers Parser
  • Check matches against your allowlist here
  • Use Host/Authority/Origin Inspect to clarify Host/Origin differences
  • Host/Authority/Origin Inspect
  • CORS Checklist
  • Request Headers Parser

What this tool does

  • Match Origin against allowlist
  • Evaluate subdomain/port rules
  • Batch-check multiple origins/rules

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)

FAQ

How should I treat null Origin?

It can appear for file:// or sandboxed iframes. Only allow it intentionally.

Are wildcards safe?

They broaden access; keep them minimal. Avoid “*” when possible.

References

  1. RFC 6454
  2. Fetch Standard
  3. MDN: CORS
  4. MDN: Origin

Page-specific case studies

Use this page to validate allowlist edge cases and prevent both over-allowing and over-blocking.

  • Check whether subdomain rules expand wider than intended.
  • Validate scheme and port conditions separately.
  • Ensure development origins are not included in production allowlists.

Page-specific implementation checklist

  • Manage allowlists in configuration, not hardcoded logic.
  • If regex is used, lock regression test cases.
  • Separate allowlists by environment (dev, staging, production).
  • Record reason and expiry when adding new allowed origins.

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

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

CORS

Compare Origin and Allow-* headers to audit CORS decisions