CORS Security Configuration Checker

Check CORS configuration for security issues free online. Detects overly permissive Access-Control-Allow-Origin settings that could expose your API to abuse.

Fetched directly from your browser.

How to Use This Tool

Enter the API endpoint URLAdd the endpoint you want to audit

Click Check CORSCORS-related headers are fetched and analyzed

Review the security verdictSee if the configuration looks overly permissive

CORS Is Often Misconfigured in the Direction of Too Permissive

Cross-Origin Resource Sharing exists to relax the browser's default same-origin restriction in controlled, deliberate ways. The problem is that developers debugging a frustrating CORS error during development often reach for the broadest possible fix -- a wildcard origin -- and that broad fix sometimes makes it to production unchanged, turning a development convenience into a production security gap.

This checker fetches an endpoint's actual CORS headers and flags patterns that are commonly problematic, particularly wildcard origins on what might be a sensitive or authenticated endpoint.

The Wildcard-Plus-Credentials Combination Browsers Actually Block

Modern browsers specifically refuse to honor Access-Control-Allow-Origin: * when Access-Control-Allow-Credentials: true is also set, precisely because that combination would let any website make authenticated requests on a logged-in user's behalf. This built-in browser protection closes off the most dangerous version of this misconfiguration, but it does not protect against wildcard-without-credentials exposing non-authenticated but still sensitive data.

Reflected Origin -- A Subtler Version of the Same Problem

Some server implementations try to be "smart" about CORS by echoing back whatever Origin header the requesting browser sent, rather than checking it against an allowlist. This looks more secure than a wildcard at a glance, but functionally permits any origin just the same, since an attacker's site simply sends its own origin and gets it reflected back as allowed.

Frequently Asked Questions

Access-Control-Allow-Origin: * combined with Access-Control-Allow-Credentials: true is a particularly dangerous combination -- browsers actually block this exact pairing because it would let any website read authenticated responses on a user's behalf. But a wildcard origin without credentials, or a poorly validated origin check, can still expose APIs to abuse from unexpected domains.

A wildcard (*) allows any domain. A reflected origin is worse in some ways -- it's when a server naively copies whatever Origin header the requester sends back into Access-Control-Allow-Origin, effectively allowing any origin while looking more restrictive than a wildcard, which is a common misconfiguration this checker specifically flags.

Not always -- a genuinely public API meant to be called from any website may intentionally use a wildcard, and that's a reasonable design choice for public data. The risk is specifically when permissive CORS is combined with sensitive or authenticated endpoints that should only be accessible from your own trusted frontend.

Access-Control-Allow-Origin set to a specific, explicitly listed trusted domain (not a wildcard) for any endpoint handling sensitive or authenticated data, with credentials only allowed for that same trusted origin -- not combined with a wildcard.

It checks the CORS headers returned for the request as sent, which reveals static misconfigurations like wildcards directly. Verifying reflected-origin behavior specifically would require sending requests with different Origin headers and comparing responses, which is a more involved test you can perform manually using this tool's raw header output as a reference.