Allow All Origins with Wildcard (*)

Wildcard Origin — The Simplest CORS Policy

The most permissive CORS configuration sets Access-Control-Allow-Origin: *, telling browsers that any origin may read the response.

Generated Headers

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, HEAD, OPTIONS
Access-Control-Max-Age: 86400

When Is Wildcard Safe?

A wildcard origin is appropriate when:

• The API serves public, read-only data (e.g., a public REST API, CDN assets, or open datasets).
• No cookies or Authorization headers are required — the credentials flag must remain false.
• The data is not user-specific and cannot be abused if any website reads it.

Key Limitation — No Credentials

The CORS specification explicitly states that when Access-Control-Allow-Credentials is true, the Allow-Origin header cannot be *. Browsers will silently discard the response. If your API uses cookies, bearer tokens in the Authorization header, or TLS client certificates, you must switch to a specific origin or a server-side dynamic check.

Nginx Example

add_header Access-Control-Allow-Origin "*" always;
add_header Access-Control-Allow-Methods "GET, HEAD, OPTIONS" always;
add_header Access-Control-Max-Age 86400 always;

Security Considerations

While convenient, * means any website in the world can make JavaScript requests to your server and read the response. For endpoints that perform write operations (POST, PUT, DELETE) or return user-specific data, always restrict the origin to trusted domains.