CORS Misconfiguration Checker

Test your web application's Cross-Origin Resource Sharing policy for critical misconfigurations that allow attackers to steal data from authenticated users.

Why CORS Misconfigurations Are Critical

CORS (Cross-Origin Resource Sharing) controls which origins can access your API. Misconfigurations can allow attackers to make cross-origin requests on behalf of authenticated victims:

Wildcard + Credentials (Access-Control-Allow-Origin: * + Allow-Credentials: true): Browsers refuse this combination, but some frameworks misconfigure it in ways that still expose data.
Reflecting Origin: Server blindly echoes back any Origin header value — effectively grants every site full access to your API with credentials.
Impact: Authenticated data theft, account takeover, CSRF bypass on APIs that rely on CORS for protection.
Fix: Maintain an explicit whitelist of allowed origins and never reflect user-controlled origin values.

Our CORS Misconfiguration Checker sends cross-origin requests with varied Origin headers and analyses how your server responds. It detects the dangerous patterns — origin reflection with credentials, wildcard misuse, and weak origin matching — that let an attacker site read authenticated data from yours.

What is CORS?

CORS (Cross-Origin Resource Sharing) is the mechanism that relaxes the browser same-origin policy. By default a page on one origin cannot read a response from another; CORS headers are how a server grants specific exceptions.

The critical header is Access-Control-Allow-Origin, which names which origins may read the response. A second header, Access-Control-Allow-Credentials, controls whether cookies and authorisation headers are included in those requests.

The combination is where the danger lies. Allowing credentials means the browser sends the victim session cookie, so a permissive origin policy does not merely expose public data — it exposes whatever the logged-in user can see.

Relaxes the same-origin policy to permit specific cross-origin reads
Access-Control-Allow-Origin names the permitted origins
Access-Control-Allow-Credentials controls whether cookies are sent
The specification forbids a wildcard origin together with credentials
Misconfiguration exposes authenticated data to any attacker site

Why CORS Misconfiguration Matters

A CORS misconfiguration turns the browser into a confused deputy. If your API reflects whatever Origin it receives and also allows credentials, any website a victim visits can issue a request to your API, the browser attaches the victim session cookie, and the attacker script reads the response.

No vulnerability in your application is required. Authentication works exactly as designed; the browser has simply been told that the attacker origin is trusted. Account data, personal information and API keys are all readable this way, and it is one of the most consistently found issues in API security assessments.

Allows an attacker site to read authenticated responses from yours
Requires no vulnerability in the application itself
Origin reflection combined with credentials is the classic dangerous pattern
Weak origin matching lets attacker-controlled lookalike domains through
Frequently found on internal and staging APIs left permissive for convenience

How This CORS Checker Works

The tool issues cross-origin requests with a range of Origin header values and inspects the response headers.

Validates the URL input against format and SSRF safety checks
Sends requests with several test Origin header values
Records the Access-Control-Allow-Origin header returned for each
Checks whether Access-Control-Allow-Credentials is also set
Identifies reflection, wildcard misuse and weak matching patterns

How to Use the CORS Checker

Enter the URL or API endpoint you want to test
Run the check to send cross-origin requests with varied origins
Review which origins the server accepts
Look carefully at whether credentials are allowed alongside a permissive origin
Tighten the policy to an explicit allowlist and re-test

Understanding Your CORS Results

The response headers reveal how permissive the policy is:

Field / Value	Meaning
`Origin reflected`	The server echoes back whatever Origin it was sent. Combined with credentials this is a critical vulnerability, because every origin is effectively trusted.
`Wildcard with credentials`	A wildcard origin together with Allow-Credentials. Browsers reject this combination, but its presence signals a misunderstanding of the policy and often accompanies other errors.
`Allow-Credentials: true`	Cookies and authorisation headers are included in cross-origin requests. Only safe when the origin policy is a strict, explicit allowlist.
`null origin accepted`	The null origin comes from sandboxed iframes and some local files, and an attacker can produce it deliberately. It should never be trusted.
`Weak origin matching`	The server accepts evil-example.com because it merely checks that the origin contains example.com. Substring matching is the most common implementation bug.
`No CORS headers`	Cross-origin reads are blocked by the browser default. This is the safest state for anything that does not need cross-origin access.

Common Problems & How to Fix Them

This is a critical finding. Any website can read authenticated responses from your API using a victim session.

Replace the reflection with an explicit allowlist. Compare the incoming Origin against a fixed set of permitted values and only echo it back on an exact match. Never construct the Allow-Origin header from untrusted input.

Checking whether the origin contains or ends with your domain lets through evil-example.com and example.com.attacker.net.

Compare the complete origin string for exact equality against your allowlist. Parse it properly rather than matching on substrings, and remember the scheme and port are part of the origin.

An attacker can cause a request to carry Origin: null from a sandboxed iframe, so treating null as trusted grants access to anyone.

Remove null from your allowlist entirely. There is no legitimate production use case that justifies the risk.

Browsers block a wildcard combined with credentials, so this configuration usually results in broken functionality that gets worked around with origin reflection — which is far worse.

Use an explicit allowlist from the outset. Reserve the wildcard for genuinely public, unauthenticated resources such as a public CDN endpoint.

Permissive settings added for development convenience routinely reach production, and internal APIs often hold the most sensitive data.

Apply the same allowlist discipline everywhere. Use environment-specific configuration so development convenience never becomes the production default.

Best Practices

Use an explicit allowlist of permitted origins rather than reflection
Compare origins by exact string equality, never by substring
Only set Allow-Credentials when the origin policy is strictly limited
Never trust the null origin
Reserve the wildcard for genuinely public unauthenticated resources
Restrict Allow-Methods and Allow-Headers to what is actually needed
Apply the same policy to staging and internal APIs as to production
Include the Vary: Origin header so caches do not serve one origin response to another

Security Recommendations

Treat origin reflection with credentials as a critical vulnerability requiring same-day remediation
Remember CORS controls reading, not sending — it does not protect against CSRF, which needs its own defences
Audit every API endpoint separately, since CORS is often configured per route and inconsistently
Set Vary: Origin so a cached response for one permitted origin is not served to another
Keep Access-Control-Max-Age short so policy changes take effect promptly
Review CORS configuration whenever a new frontend or partner integration is added

Frequently Asked Questions

It is a CORS policy permissive enough to let untrusted websites read responses from your server. The most dangerous form reflects whatever Origin is received while also allowing credentials, which effectively trusts every origin on the internet.

Because it means every origin is permitted. Combined with Allow-Credentials, any site a victim visits can request your API, have the browser attach the victim session cookie, and read the authenticated response.

No. It is appropriate for genuinely public, unauthenticated resources such as a public CDN or open data endpoint. It becomes dangerous when the endpoint returns anything user-specific, and browsers block it entirely when credentials are allowed.

No, and conflating the two is a common mistake. CORS governs whether a response can be read. CSRF is about a request being sent at all, which the same-origin policy does not prevent. Use anti-CSRF tokens and SameSite cookies for that.

Origin: null is sent by sandboxed iframes, redirects in some cases, and local files. An attacker can deliberately produce it, so allowing null is equivalent to allowing anyone. It should never appear in an allowlist.

Maintain a fixed allowlist and compare the incoming Origin for exact equality, including scheme and port. Only echo it back on a match. Never use substring, prefix or suffix matching, which is the source of most implementation bugs.

Only if a browser on a different origin needs to read your responses. If everything is same-origin, or consumed by server-side clients that ignore CORS entirely, sending no CORS headers is the safest configuration.