What is CORS and why does it matter?

CORS (Cross-Origin Resource Sharing) is a security mechanism that allows web servers to specify which origins (domains) can access their resources. It's implemented through HTTP headers and enforced by web browsers. CORS matters because misconfigured policies can lead to serious security vulnerabilities including data theft, session hijacking, and account takeover. According to recent security research, nearly 90% of API breaches begin with misconfigured CORS policies.

What are the most common CORS misconfigurations?

The most common and dangerous CORS misconfigurations include: (1) Wildcard origin with credentials enabled - allows any website to make authenticated requests, (2) Origin reflection - server echoes any origin without validation, (3) Null origin acceptance - allows exploitation via sandboxed iframes, (4) Overly permissive methods - exposing PUT, DELETE, PATCH to all origins, (5) Missing Vary: Origin header - can lead to cache poisoning, and (6) Subdomain trust issues - accepting all subdomains without validation.

Why is wildcard origin with credentials dangerous?

Setting Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true is a critical security vulnerability. This configuration allows ANY website to make authenticated requests to your API and access sensitive data. An attacker can create a malicious website that tricks users into visiting it, then uses their browser cookies and credentials to access your API and steal data. This can lead to account takeover, data theft, and session hijacking. Never use wildcard origins with credentials - always use explicit origin whitelists.

How do I test if my CORS policy is secure?

To test your CORS policy: (1) Use this tool to scan your API endpoints and review the vulnerability report, (2) Test with different origin values using browser developer tools or curl, (3) Verify that only trusted origins are accepted, (4) Ensure credentials are only allowed for specific trusted domains, (5) Check that HTTP methods are restricted appropriately, (6) Verify Vary: Origin header is present, and (7) Conduct penetration testing with security professionals. Automated testing should be part of your CI/CD pipeline.

What is a CORS preflight request?

A preflight request is an OPTIONS request sent by the browser before certain cross-origin requests to check if the server allows the actual request. Preflight requests are triggered by requests with custom headers, methods other than GET/HEAD/POST, or Content-Type other than application/x-www-form-urlencoded, multipart/form-data, or text/plain. The server responds with Access-Control-Allow-Methods and Access-Control-Allow-Headers to indicate what is permitted. Browsers cache preflight responses based on Access-Control-Max-Age.

Can this tool test any URL?

Due to browser CORS restrictions, this tool can only analyze URLs that already allow cross-origin requests from this domain. The tool is limited by the same security mechanisms it analyzes. For comprehensive CORS testing including origin reflection, null origin acceptance, and credential testing, you'll need to use server-side tools like Burp Suite, OWASP ZAP, curl, or custom scripts that aren't subject to browser CORS restrictions.

How do I implement secure CORS in my application?

To implement secure CORS: (1) Use explicit origin whitelists - never use wildcards in production, (2) Only enable credentials for specific trusted origins, (3) Restrict HTTP methods to minimum required (typically GET, POST), (4) Validate origins server-side, don't just reflect the Origin header, (5) Include Vary: Origin header to prevent cache poisoning, (6) Set reasonable Max-Age (24 hours or less), (7) Regularly audit CORS policies, and (8) Test changes before deployment. Use framework-specific CORS libraries that handle these details correctly.

What is origin reflection and why is it dangerous?

Origin reflection is when a server echoes back whatever origin value is sent in the request header without validation. For example, if an attacker sends Origin: https://evil.com, the server responds with Access-Control-Allow-Origin: https://evil.com. This allows attackers to bypass origin validation entirely and access resources from any domain they control. Origin reflection is especially dangerous when combined with Access-Control-Allow-Credentials: true, as it enables complete cross-origin data theft and session hijacking.

Home/Tools/Security/CORS Policy Analyzer

CORS Policy Analyzer

Detect and analyze CORS misconfigurations that could lead to data exposure and security breaches. Test origin validation, credential handling, and policy implementation.

100% Private - Runs Entirely in Your Browser

No data is sent to any server. All processing happens locally on your device.

How CORS Works

CORS (Cross-Origin Resource Sharing) is a browser security feature that controls how web pages from one domain can request resources from another domain. Understanding how CORS works is essential for building secure APIs and web applications.

Same-Origin Policy

By default, browsers enforce the Same-Origin Policy (SOP), which prevents JavaScript code from one origin (domain, protocol, and port) from accessing resources at a different origin. This is a fundamental security mechanism that prevents malicious websites from stealing data.

Two URLs have the same origin only if they match in protocol, domain, and port. For example:

https://example.com/page1 and https://example.com/page2 - Same origin ✓

https://example.com and http://example.com - Different origin (protocol) ✗

https://example.com and https://api.example.com - Different origin (subdomain) ✗

https://example.com:443 and https://example.com:8080 - Different origin (port) ✗

CORS Headers

CORS relaxes the Same-Origin Policy by using HTTP headers to tell browsers which cross-origin requests are allowed. The most important CORS headers are:

Access-Control-Allow-Origin

Specifies which origins can access the resource. Can be a specific origin ( https://trusted.com), wildcard (*), or null.

Access-Control-Allow-Credentials

Indicates whether cookies and authorization headers can be sent. Must be true (cannot use wildcard origin with credentials).

Access-Control-Allow-Methods

Specifies which HTTP methods are allowed (GET, POST, PUT, DELETE, etc.).

Access-Control-Allow-Headers

Lists which headers can be used in the actual request (e.g., Content-Type, Authorization).

Access-Control-Max-Age

How long (in seconds) preflight response can be cached. Recommended: 86400 seconds (24 hours) or less.

Simple vs Preflight Requests

CORS distinguishes between simple requests and preflight requests:

Simple Requests

Simple requests are sent directly without a preflight check. They must meet these conditions:

Method: GET, HEAD, or POST

Headers: Only Accept, Accept-Language, Content-Language, Content-Type (with limited values)

Content-Type: application/x-www-form-urlencoded, multipart/form-data, or text/plain

Preflight Requests

Preflight requests are triggered when a request doesn't meet "simple" criteria. The browser sends an OPTIONS request first to check permissions:

Browser sends OPTIONS request with Access-Control-Request-Method and headers
Server responds with allowed methods, headers, and origins
If approved, browser sends the actual request
Preflight response is cached based on Access-Control-Max-Age

Common CORS Vulnerabilities

🔴 Critical: Wildcard Origin with Credentials

Configuration: Access-Control-Allow-Origin: * + Access-Control-Allow-Credentials: true

Impact: Any website can make authenticated requests and steal user data, sessions, and credentials. This is the most severe CORS misconfiguration.

Attack: Attacker creates malicious website that uses victim's cookies to access your API and exfiltrate data.

Fix: Never use wildcard with credentials. Use explicit origin whitelist: Access-Control-Allow-Origin: https://trusted.com

🟠 High: Origin Reflection

Configuration: Server echoes any origin from request: Access-Control-Allow-Origin: $ORIGIN_HEADER

Impact: Bypasses origin validation entirely. Attackers can access resources from any domain.

Detection: Send request with Origin: https://evil.com - if server responds with same origin, it's vulnerable.

Fix: Validate origin against whitelist server-side before setting CORS headers. Never blindly reflect Origin header.

🟡 Medium: Null Origin Accepted

Configuration: Access-Control-Allow-Origin: null

Impact: Allows exploitation via sandboxed iframes or file:// protocol. Attackers can use <iframe sandbox> to generate null origin.

Attack: Malicious page creates sandboxed iframe that makes requests with null origin.

Fix: Never accept null origin. Only allow explicit trusted domains.

Security Best Practices

✓

Use explicit origin whitelist

Maintain a list of trusted domains. Validate origin server-side against this list.

✓

Never use wildcard with credentials

If credentials are needed, specify exact origin. Wildcard + credentials = critical vulnerability.

✓

Restrict HTTP methods

Only allow necessary methods (GET, POST). Restrict PUT, DELETE, PATCH to authenticated origins.

✓

Include Vary: Origin header

Prevents cache poisoning attacks. Tells caches to vary response based on Origin header.

✓

Set reasonable Max-Age

Limit preflight cache to 24 hours (86400 seconds) or less for timely security updates.

✓

Regular security audits

Audit CORS policies quarterly and after any API changes. Include in CI/CD pipeline.

✓

Test before deployment

Use this tool and other security scanners to verify configuration before going live.

## How CORS Works CORS (Cross-Origin Resource Sharing) is a browser security feature that controls how web pages from one domain can request resources from another domain. Understanding how CORS works is essential for building secure APIs and web applications. ### Same-Origin Policy By default, browsers enforce the Same-Origin Policy (SOP), which prevents JavaScript code from one origin (domain, protocol, and port) from accessing resources at a different origin. This is a fundamental security mechanism that prevents malicious websites from stealing data. Two URLs have the same origin only if they match in protocol, domain, and port. For example: - `https://example.com/page1` and `https://example.com/page2` - Same origin ✓ - `https://example.com` and `http://example.com` - Different origin (protocol) ✗ - `https://example.com` and `https://api.example.com` - Different origin (subdomain) ✗ - `https://example.com:443` and `https://example.com:8080` - Different origin (port) ✗ ### CORS Headers CORS relaxes the Same-Origin Policy by using HTTP headers to tell browsers which cross-origin requests are allowed. The most important CORS headers are: `Access-Control-Allow-Origin` Specifies which origins can access the resource. Can be a specific origin ( `https://trusted.com`), wildcard (`*`), or null. `Access-Control-Allow-Credentials` Indicates whether cookies and authorization headers can be sent. Must be `true` (cannot use wildcard origin with credentials). `Access-Control-Allow-Methods` Specifies which HTTP methods are allowed (GET, POST, PUT, DELETE, etc.). `Access-Control-Allow-Headers` Lists which headers can be used in the actual request (e.g., Content-Type, Authorization). `Access-Control-Max-Age` How long (in seconds) preflight response can be cached. Recommended: 86400 seconds (24 hours) or less. ### Simple vs Preflight Requests CORS distinguishes between simple requests and preflight requests: Simple Requests Simple requests are sent directly without a preflight check. They must meet these conditions: - Method: GET, HEAD, or POST - Headers: Only Accept, Accept-Language, Content-Language, Content-Type (with limited values) - Content-Type: application/x-www-form-urlencoded, multipart/form-data, or text/plain Preflight Requests Preflight requests are triggered when a request doesn't meet "simple" criteria. The browser sends an OPTIONS request first to check permissions: - Browser sends OPTIONS request with Access-Control-Request-Method and headers - Server responds with allowed methods, headers, and origins - If approved, browser sends the actual request - Preflight response is cached based on Access-Control-Max-Age ## Common CORS Vulnerabilities ### 🔴 Critical: Wildcard Origin with Credentials Configuration: `Access-Control-Allow-Origin: *` + `Access-Control-Allow-Credentials: true` Impact: Any website can make authenticated requests and steal user data, sessions, and credentials. This is the most severe CORS misconfiguration. Attack: Attacker creates malicious website that uses victim's cookies to access your API and exfiltrate data. Fix: Never use wildcard with credentials. Use explicit origin whitelist: `Access-Control-Allow-Origin: https://trusted.com` ### 🟠 High: Origin Reflection Configuration: Server echoes any origin from request: `Access-Control-Allow-Origin: $ORIGIN_HEADER` Impact: Bypasses origin validation entirely. Attackers can access resources from any domain. Detection: Send request with `Origin: https://evil.com` - if server responds with same origin, it's vulnerable. Fix: Validate origin against whitelist server-side before setting CORS headers. Never blindly reflect Origin header. ### 🟡 Medium: Null Origin Accepted Configuration: `Access-Control-Allow-Origin: null` Impact: Allows exploitation via sandboxed iframes or file:// protocol. Attackers can use `