Wildcard vs Dynamic Origin Reflection: When to Use Each

Two server responses grant cross-origin access: a static Access-Control-Allow-Origin: *, and a dynamically reflected origin echoed back after validation. Choosing the wrong one either breaks credentialed requests or opens the API to every website on the internet. The decision is not a matter of taste — it follows directly from whether the endpoint handles credentials or caller-scoped data.

This page is part of CORS Security Auditing & Hardening, which covers the full process of finding and closing CORS misconfigurations.

The Decision in One Table

Root Cause: Why the Choice Is Forced

The WHATWG Fetch Standard (§3.2.3) makes one combination illegal: Access-Control-Allow-Origin: * cannot appear with Access-Control-Allow-Credentials: true. The browser checks this at response evaluation and blocks the read. So any endpoint that needs cookies or tokens cannot use a wildcard — it must echo the exact origin. Conversely, an endpoint that is genuinely public and credential-free gains nothing from reflection and is simpler and more cache-friendly with a wildcard, because the response body and headers are identical for every caller. The mechanics of this prohibition are detailed in Understanding Access-Control-Allow-Credentials.

Prerequisite State

• You know whether the endpoint sends credentials (fetch(..., { credentials: 'include' }), cookies, or Authorization).
• You know whether the response body is public or scoped to the caller.
• You have a defined list of trusted front-end origins if reflection is required.

Step-by-Step: Pick and Implement

Step 1 — Classify the endpoint

Ask two questions: does it carry credentials, and does it return caller-specific data? A “yes” to either rules out the wildcard.

Step 2a — Public + credential-free → wildcard

location /public/ {
  add_header Access-Control-Allow-Origin "*" always;
  # No Allow-Credentials, no Vary: Origin needed — response is identical for all
}

Step 2b — Credentialed or scoped → validated reflection

Match the origin against an allowlist and reflect only the matched value, adding Vary: Origin so caches key per origin:

const ALLOWED = new Set([
  'https://app.example.com',
  'https://admin.example.com',
]);

app.use((req, res, next) => {
  const origin = req.headers.origin;
  if (origin && ALLOWED.has(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Access-Control-Allow-Credentials', 'true');
    res.setHeader('Vary', 'Origin');
  }
  next();
});

For the allowlist architecture and subdomain-safe matching, see Dynamic Origin Validation Patterns.

Verification

# Public endpoint: wildcard is fine
curl -si https://api.example.com/public/data -H "Origin: https://anything.example" | grep -i access-control-allow-origin
# → access-control-allow-origin: *

# Credentialed endpoint: exact reflection, and deny for unknown origins
curl -si https://api.example.com/v1/me -H "Origin: https://app.example.com" | grep -i access-control
# → access-control-allow-origin: https://app.example.com  +  access-control-allow-credentials: true
curl -si https://api.example.com/v1/me -H "Origin: https://attacker.example" | grep -i access-control-allow-origin
# → (no header — correctly denied)

Security Boundary Note

Never reflect the Origin header without validating it against an allowlist. Unvalidated reflection behaves like a wildcard that also works with credentials, letting any website read authenticated responses — a direct data-exfiltration and CSRF-amplification vector. If you find yourself reaching for Access-Control-Allow-Origin: * on an endpoint that uses credentials, the answer is not a wildcard and not blind reflection; it is a validated allowlist. Deeper threat modelling is in Wildcard Risks & Mitigation.

Common Mistakes

FAQ