CORS Policy Analyzer

Test and Debug CORS Configurations

Cross-Origin Resource Sharing (CORS) controls which domains can access your API. Misconfigured CORS can block legitimate requests or expose your API to attacks.

What We Check

• Access-Control-Allow-Origin: Allowed origins
• Access-Control-Allow-Methods: Permitted HTTP methods
• Access-Control-Allow-Headers: Custom headers allowed
• Access-Control-Allow-Credentials: Cookie/auth support
• Preflight handling: OPTIONS request responses

Common Issues

Wildcard origins with credentials, missing preflight handling, overly permissive configurations.

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 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 are triggered when a request doesn't meet "simple" criteria. The browser sends an OPTIONS request first to check permissions:

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

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.

Low: Missing Vary Header

Configuration: CORS headers without Vary: Origin

Impact: Can lead to cache poisoning attacks where cached responses are served to wrong origins.

Fix: Always include Vary: Origin header when using dynamic CORS responses.

Medium: Overly Permissive Methods

Configuration: Allowing dangerous methods like PUT, DELETE, PATCH for all origins

Impact: Unauthorized data modification, resource deletion, privilege escalation.

Fix: Only allow necessary HTTP methods (GET, POST). Restrict destructive methods to authenticated origins.

Essential CORS Security Checklist

✓ 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.

✓ Validate origins server-side - Never blindly reflect the Origin header. Implement proper whitelist validation.

Secure Configuration Examples

Express.js (Node.js)

const cors = require('cors');

const corsOptions = {
  origin: function (origin, callback) {
    const allowedOrigins = [
      'https://yourdomain.com',
      'https://app.yourdomain.com'
    ];

    if (!origin || allowedOrigins.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
  credentials: true,
  methods: ['GET', 'POST'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  maxAge: 86400
};

app.use(cors(corsOptions));

Django (Python)

# settings.py
CORS_ALLOWED_ORIGINS = [
    "https://yourdomain.com",
    "https://app.yourdomain.com",
]

CORS_ALLOW_CREDENTIALS = True

CORS_ALLOWED_METHODS = [
    "GET",
    "POST",
]

CORS_ALLOWED_HEADERS = [
    "content-type",
    "authorization",
]

CORS_PREFLIGHT_MAX_AGE = 86400

Nginx

location /api {
    if ($http_origin ~* (https://yourdomain.com|https://app.yourdomain.com)) {
        add_header 'Access-Control-Allow-Origin' $http_origin always;
        add_header 'Access-Control-Allow-Credentials' 'true' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST' always;
        add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization' always;
        add_header 'Vary' 'Origin' always;
    }

    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Max-Age' 86400 always;
        add_header 'Content-Length' 0;
        return 204;
    }
}