DevTools Logo

CORS Header Validator

CORS Header Validator

Validate Cross-Origin Resource Sharing (CORS) headers for security and compliance

Request Configuration

The URL making the cross-origin request

The API/resource URL being requested

Enter response headers from the server (one per line, in "Name: Value" format)

CORS Headers Reference

Response Headers:

  • Access-Control-Allow-Origin - Allowed origins
  • Access-Control-Allow-Methods - Allowed HTTP methods
  • Access-Control-Allow-Headers - Allowed request headers
  • Access-Control-Allow-Credentials - Allow cookies/auth
  • Access-Control-Max-Age - Preflight cache duration
  • Access-Control-Expose-Headers - Exposed response headers

Best Practices:

  • • Avoid wildcard (*) in production
  • • Use specific origins when possible
  • • Be cautious with credentials
  • • Limit allowed methods and headers
  • • Use HTTPS for secure applications
  • • Set appropriate cache duration
Learn More:

For detailed CORS documentation, visit theMDN CORS Guide

    Examples

    Production single-origin API with auth

    Input
    Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 86400
    Output
    Errors:      (none)
Warnings:    ["Potentially unsafe HTTP methods allowed: PUT, DELETE"]
Recommendations: (none)
Valid: yes

    A single explicit HTTPS origin with credentials is the spec-compliant ideal. PUT and DELETE trigger the only warning — they're conventionally less-used and worth pinning with an allowlist. Max-Age 86400 sits exactly at the 24-hour ceiling the validator recommends.

    Wildcard origin paired with credentials (security violation)

    Input
    Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
    Output
    Errors:      ["Cannot use wildcard origin (*) with Access-Control-Allow-Credentials: true"]
Warnings:    ["Wildcard (*) origin allows requests from any domain"]
Recommendations: ["Use HTTPS when allowing credentials", "Consider setting Access-Control-Max-Age to cache preflight requests", "Specify allowed HTTP methods explicitly"]
Valid: no

    The Fetch standard forbids the wildcard origin when credentials are enabled; the browser blocks the response regardless of what the server returns. Replace * with a single explicit origin or with dynamic origin echo after a server-side allowlist.

    Empty header block — what is missing

    Input
    (no headers)
    Output
    Errors:      ["Missing Access-Control-Allow-Origin header"]
Recommendations: ["Use HTTPS origins for better security", "Consider setting Access-Control-Max-Age to cache preflight requests", "Specify allowed HTTP methods explicitly"]
Valid: no

    Without Access-Control-Allow-Origin the browser treats every cross-origin response as opaque and blocks JS from reading it. The three recommendations point to the most-common baseline: an explicit HTTPS origin, a caching duration for preflights, and a methods allowlist.

    About this tool

    CORS (Cross-Origin Resource Sharing) is the browser security protocol that decides whether a response from one origin may be read by code on another. A correct response carries one or more Access-Control-* headers; a mismatch in any one of them can silently block a valid frontend request or, worse, expose an API more broadly than intended. The validator parses a raw response-header block and audits each of the six headers against the Fetch standard and real-world security pitfalls.

    It surfaces four classes of finding. Errors block the browser from completing the request — most often a wildcard origin paired with credentials, which the spec forbids. Warnings flag risky but technically-valid configurations like wildcard origins, unsafe HTTP methods, or Max-Age values that exceed the 24-hour upper bound the spec recommends. Recommendations highlight missing best-practice headers, such as not specifying allowed methods at all. Parsing happens entirely in the browser; the headers you paste are never sent anywhere.

    An optional Origin/Target URL pair adds cross-origin checks: same-origin detection, origin-allowlist membership, and HTTPS verification of the calling origin. The tool does not fetch your site — it only audits the text you provide, so it's safe to paste headers copied from developer tools, curl, internal staging, or third-party APIs.

    How to use

    1. Paste the response headers

      Copy a raw HTTP response-header block from curl or the browser's Network panel and paste it into the textarea — one Name: Value pair per line.

    2. Add origin and target URLs (optional)

      Fill in the Origin URL (the page making the request) and Target URL (the API being called). The validator then checks whether the request will be allowed end-to-end.

    3. Read errors, warnings, recommendations

      Click Validate CORS Headers. Errors block the request, warnings describe risky configurations, and recommendations close common gaps like missing Max-Age.

    4. Iterate until clean

      Update your server or middleware, paste the fresh headers, and re-validate until errors drop to zero. The parsed header view surfaces the exact values being sent.

    Use cases

    Auditing a third-party API before integrating

    Paste the response headers copied from curl and see exactly which Access-Control-* values the API exposes — and whether they will block your browser code before you wire up fetch calls.

    Reviewing a CORS change in a PR

    When a teammate pushes a server config change that touches CORS, paste the new response headers and confirm the diff didn't relax security (for example accidentally widening a wildcard) or break credentials.

    Debugging a blocked preflight

    When the browser console reports a preflight failure, paste the OPTIONS response and check whether Access-Control-Allow-Headers lists every non-safelisted header the client is sending.

    Validating a CORS middleware during local development

    Paste headers from your dev server (Express cors(), Flask-CORS, Spring, your reverse proxy) and check that the rule you wrote matches the rule that is being emitted — typos in middleware options are a common silent break.

    Common mistakes

    Mistake:Returning Access-Control-Allow-Origin: * together with Access-Control-Allow-Credentials: true.

    Fix:The Fetch standard forbids the combination. Replace * with the specific origin or echo the request Origin after a server-side allowlist, and remove Allow-Credentials if the API is truly public.

    Mistake:Believing the Access-Control-Allow-Origin header can list multiple origins.

    Fix:The header accepts a single origin or *. Multiple origins need a server-side allowlist and a dynamic echo of the request's Origin — list the allowed origins in your code, not in the header value.

    Mistake:Listing every HTTP method in Access-Control-Allow-Methods because it is easier.

    Fix:Restrict the list to methods the API actually serves — the validator flags PUT, DELETE, PATCH, TRACE, and CONNECT as 'potentially unsafe'. A tight allowlist is also what the browser's preflight matches against.

    Mistake:Using a Max-Age over 86400 to cache preflights 'forever'.

    Fix:Browser implementations clamp Max-Age to 24 hours. Pick a value that reflects how often your policy changes — 600s while iterating, 86400s for stable APIs.

    Mistake:Trusting the validator's 'valid' badge as a full security review.

    Fix:A passing validation means the headers conform to the spec and common pitfalls; it does not prove your origin allowlist is the right one, that your server-side validator rejects bad origins, or that authentication tokens are kept safe end-to-end.

    Frequently asked questions

    Related guides

    CORS Explained: A Practical Guide for Web Developers

    Understand Cross-Origin Resource Sharing from the browser up. Learn why CORS is a browser mechanism, the difference between simple and preflight requests, the wildcard-with-credentials pitfall, and how to read Access-Control-* headers.

    HTTP Status Codes Every Developer Should Know

    A field guide to HTTP status codes — what each 1xx–5xx class means, the codes you will meet every day, and the common mistakes people make reading them.

    References & standards

    Related tools

    AES Encryption

    Encrypt and decrypt text with AES-GCM and a passphrase, fully in your browser. Uses PBKDF2 key derivation and the Web Crypto API — your data and keys never leave your device.

    Basic Auth Generator

    Generate an HTTP Basic Authentication header from a username and password. Produces the Authorization header and ready-to-use curl and fetch snippets. Runs fully client-side.

    Bcrypt Generator & Verifier

    Hash passwords with bcrypt and verify hashes — choose your cost factor (rounds 4–15), get a secure hash instantly, and check whether a password matches a hash. Runs entirely in your browser.

    BIP39 Mnemonic Generator

    Generate and validate BIP39 seed phrases locally for testing

    Checksum Calculator

    Compute file checksums (SHA-1, SHA-256, SHA-384, SHA-512) in your browser with the Web Crypto API

    CORS Policy Builder

    Build CORS response headers, Nginx directives, and JavaScript fetch examples for safe cross-origin requests and preflight handling