Security & Web Utilities • Published August 18, 2026

Understanding Access-Control-Allow-Origin: Syntax, Wildcards & Security Pitfalls

Master the Access-Control-Allow-Origin HTTP header. Understand wildcard vs specific origins, dynamic origin validation, credentials matching, and security best practices.

Deep dive into the Access-Control-Allow-Origin header. Learn how wildcards work, dynamic origin reflection, credentials handling, and how to avoid critical security vulnerabilities.

Frequently Asked Questions

Q1. Can I put multiple origins in Access-Control-Allow-Origin separated by commas?

No. The HTTP specification for Access-Control-Allow-Origin only allows either a single exact origin (e.g., https://app.example.com), "" (wildcard), or "null". To support multiple domains, your server must inspect the incoming Origin header against an allowlist and dynamically return the matched origin.

Q2. Why does Access-Control-Allow-Origin: fail when sending cookies or JWT headers?

To protect user privacy, W3C specifications explicitly forbid browsers from exposing authenticated responses (cookies or HTTP Authorization headers) when the server specifies a wildcard () origin. The server MUST specify the exact origin.

Q3. What happens if Access-Control-Allow-Origin is set to "null"?

Setting Access-Control-Allow-Origin to "null" is dangerous. Sandboxed iframes, local file:// URLs, and redirected requests can send "Origin: null", enabling cross-origin data theft if reflected.