CORS Security — Protecting Your API from Cross-Origin Attacks

In this tutorial, you will learn about CORS Security. We cover key concepts, practical examples, and best practices to help you master this topic.

CORS security is about finding the right balance between accessibility and protection, ensuring your API allows legitimate cross-origin requests while preventing abuse from malicious sites.

What You'll Learn

• Security risks of misconfigured CORS
• How CORS interacts with CSRF and XSS
• Best practices for secure CORS configuration

Why It Matters

A single misconfigured CORS header can expose your entire API to cross-origin attacks. Understanding CORS security prevents data breaches.

flowchart TD
    A["CORS Security Risks"] --> B["Wildcard Origin\nwith Auth"]
    A --> C["Reflecting Untrusted\nOrigin Headers"]
    A --> D["Permissive\nPreflight Caching"]
    A --> E["Exposing Sensitive\nResponse Headers"]
    B --> F["Any site can read\nyour user's data"]
    C --> G["Attacker's origin\nreflected back"]
    D --> H["Stale permissions\ncached too long"]
    style A fill:#dbeafe,stroke:#2563eb

Code Examples

# Insecure CORS configuration
CORS_ALLOW_ALL_ORIGINS = True  # NEVER in production
CORS_ALLOW_CREDENTIALS = True   # Dangerous with all origins

# Secure configuration
CORS_ALLOWED_ORIGINS = [
    "https://trusted-app.com",
]
CORS_ALLOW_CREDENTIALS = True

// Never reflect Origin header blindly
app.use((req, res, next) => {
  // INSECURE: echoes any origin
  res.header('Access-Control-Allow-Origin', req.headers.origin);

  // SECURE: validates before echoing
  const allowed = ['https://myapp.com', 'https://admin.myapp.com'];
  if (allowed.includes(req.headers.origin)) {
    res.header('Access-Control-Allow-Origin', req.headers.origin);
  }
});

Common Mistakes

1. Reflecting Arbitrary Origin Headers

An attacker can set Origin: https://evil.com and the server echoes it back.

2. Using null Origin

The null origin can be sent from sandboxed iframes. Avoid allowing it.

3. Allowing Too Many Methods

Attackers can use methods like PUT or DELETE if you allow them unnecessarily.

4. Setting Max-Age Too Long

Changes to CORS policies take time to propagate if preflight responses are cached.

5. Thinking CORS Replaces Server-Side Auth

CORS is browser-enforced. Attackers can make server-to-server requests without CORS.

Practice Questions

1. What is the most dangerous CORS Misconfiguration?
2. Why is reflecting the Origin header insecure?
3. Can CORS prevent CSRF Attacks?
4. What is the risk of allowing all methods?
5. How does preflight Caching affect security?

Answers:

1. Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true.
2. An attacker can set any origin, and the server will accept it.
3. No. CSRF attacks don't read responses; they send requests. CORS only blocks reading responses.
4. Attackers can use DELETE to remove data or PUT to modify it.
5. Long cache times mean policy changes take effect slowly.

Challenge: Audit a CORS configuration for security issues. Given a config that allows all origins, all methods, and credentials, identify all vulnerabilities and provide a secure alternative.

FAQ

What's Next

Learn CORS Troubleshooting techniques, then build a CORS Mini Project to apply your knowledge.