Dynamic Origin Validation Patterns

Without server-side origin validation, a CORS implementation must choose between a static list that breaks at the first new tenant or a wildcard that surrenders every credential isolation guarantee. Dynamic validation is the runtime path between those extremes: the server evaluates the incoming Origin header on each request, confirms it belongs to an allowlist, and conditionally reflects it — never echoing blindly, never falling back to *. This page is a sub-topic of Server-Side CORS Configuration & Header Management, which covers the full header lifecycle from request parsing to response delivery.

The WHATWG Fetch Standard (section 3.2, “HTTP-network fetch”) requires exact string equality between the request Origin and the Access-Control-Allow-Origin value in the response when credentials are involved. That rule makes origin reflection safe only after verified membership in a controlled set.

Origin Header Reference

Understanding what the browser sends — and in what form — is the prerequisite for writing validation logic that cannot be bypassed.

How the Validation Decision Flows

The diagram below shows the server-side decision path from receiving an Origin header to emitting — or withholding — Access-Control-Allow-Origin.

Both the match and no-match branches append Vary: Origin. Omitting it on the no-match branch still allows a cached “no ACAO header” response to be served to a legitimate origin that hits the same CDN node next.

Step-by-Step Implementation

1. Parse and normalise the incoming Origin

The WHATWG Fetch Standard defines the origin as a tuple of scheme, host, and optional port. Before any comparison, lowercase the host component and strip any trailing slash. Do not strip the port — https://app.example.com:443 and https://app.example.com are distinct strings even though port 443 is the HTTPS default.

function normaliseOrigin(raw) {
  if (!raw || raw === 'null') return raw;   // preserve the literal "null" for separate handling
  try {
    const url = new URL(raw);
    return `${url.protocol}//${url.hostname.toLowerCase()}${url.port ? ':' + url.port : ''}`;
  } catch {
    return null;   // unparseable — treat as invalid
  }
}

2. Validate against an exact-match allowlist (Express.js)

For Access-Control-* header directives that must vary per caller, exact matching is the safest baseline. Load the allowlist from an environment variable or a cache-backed store:

const ALLOWED_ORIGINS = new Set(
  (process.env.ALLOWED_ORIGINS || '').split(',').map(s => s.trim()).filter(Boolean)
);

app.use((req, res, next) => {
  const origin = normaliseOrigin(req.headers.origin);
  if (origin && ALLOWED_ORIGINS.has(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Vary', 'Origin');
  } else {
    // Still vary so caches do not serve this no-ACAO response to a valid origin
    res.setHeader('Vary', 'Origin');
  }
  next();
});

3. Extend with anchored regex for multi-tenant routing

When tenant subdomains are provisioned dynamically, exact matching becomes impractical. Regex is acceptable only with full anchoring and an explicit scheme prefix. For the full implementation details, see Express.js dynamic origin allowlist implementation.

// GOOD: anchored, scheme-explicit, character class limited
const TENANT_PATTERN = /^https:\/\/[a-z0-9-]{1,63}\.tenant\.example\.com$/;

// BAD: unanchored — matches "evil-tenant.example.com.attacker.io"
// const TENANT_PATTERN = /tenant\.example\.com/;

app.use((req, res, next) => {
  const origin = normaliseOrigin(req.headers.origin);
  const isValid = origin && (
    ALLOWED_ORIGINS.has(origin) ||
    TENANT_PATTERN.test(origin)
  );
  res.setHeader('Vary', 'Origin');
  if (isValid) {
    res.setHeader('Access-Control-Allow-Origin', origin);
  }
  next();
});

4. Handle preflight separately

Validation logic must also gate OPTIONS preflight requests before the browser sends the actual request:

app.options('*', (req, res) => {
  const origin = normaliseOrigin(req.headers.origin);
  const isValid = origin && (ALLOWED_ORIGINS.has(origin) || TENANT_PATTERN.test(origin));
  res.setHeader('Vary', 'Origin');
  if (isValid) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Access-Control-Allow-Methods', 'GET,POST,PUT,DELETE,PATCH');
    res.setHeader('Access-Control-Allow-Headers', 'Content-Type,Authorization');
    res.setHeader('Access-Control-Max-Age', '3600');
  }
  res.status(isValid ? 204 : 403).end();
});

5. Infrastructure-level validation with Nginx

For configuring CORS in Nginx for multiple origins, use a map block to resolve the incoming origin to a variable that is either the origin itself or an empty string. Emitting the header with an empty value is distinct from omitting it entirely, so use a conditional block:

map $http_origin $cors_origin_valid {
  default              "";
  "https://app.example.com"   "$http_origin";
  "https://admin.example.com" "$http_origin";
  "~^https://[a-z0-9-]+\.tenant\.example\.com$" "$http_origin";
}

server {
  location /api/ {
    # Only emit the header when the map resolved to a non-empty value
    if ($cors_origin_valid) {
      add_header Access-Control-Allow-Origin $cors_origin_valid always;
    }
    add_header Vary Origin always;

    if ($request_method = OPTIONS) {
      add_header Access-Control-Allow-Methods "GET,POST,PUT,DELETE,PATCH" always;
      add_header Access-Control-Allow-Headers "Content-Type,Authorization" always;
      add_header Access-Control-Max-Age 3600 always;
      return 204;
    }

    proxy_pass http://backend;
  }
}

The always flag forces Nginx to include the header even on error responses. Without it, 4xx and 5xx responses omit CORS headers and the browser blocks the error body from JavaScript — hiding the real failure reason.

6. Database-backed allowlist with TTL caching

For runtime tenant onboarding without service restarts, back the allowlist with a database query and a short-lived in-process cache:

const cache = new Map();
const CACHE_TTL_MS = 5 * 60 * 1000;

async function isOriginAllowed(origin, db) {
  const cached = cache.get(origin);
  if (cached !== undefined) return cached;

  const { rowCount } = await db.query(
    'SELECT 1 FROM cors_allowlist WHERE origin = $1 AND active = TRUE',
    [origin]
  );
  const valid = rowCount > 0;
  cache.set(origin, valid);
  setTimeout(() => cache.delete(origin), CACHE_TTL_MS);
  return valid;
}

Add a circuit breaker around the database call. If the store is unreachable, fail closed (reject the origin) rather than falling back to a permissive default. Log the validation result and origin value on every request for audit purposes.

Edge Cases and Security Boundaries

The null origin

Sandboxed iframes with no allow-same-origin attribute, data: URLs, and certain redirect chains all send Origin: null. This is a literal string, not an absent header. Adding "null" to an allowlist is dangerous because any cross-origin iframe — including attacker-controlled ones — produces the same value. Accept null only for specific controlled embed use cases where the embedding page is under your control, and document the decision explicitly.

Subdomain normalisation edge cases

https://app.example.com and https://APP.EXAMPLE.COM are the same origin per the URL Standard (hosts are case-insensitive), but string comparison treats them as different. Always lowercase before comparing. Port omission is trickier: the browser includes the port when it is non-default (https://app.example.com:8443) and omits it when it is default (https://app.example.com for port 443). Validate against what the browser actually sends, not what you expect it to send.

Opaque responses and no-cors mode

When JavaScript initiates a fetch with mode: 'no-cors', the browser makes the request but returns an opaque response (type "opaque", status 0, body unreadable). No Origin validation is relevant because the browser never reads the response headers. The risk here is server-side state mutation from the unvalidated request — enforce authentication and CSRF tokens independently of CORS.

Wildcard risks

Never fall back to Access-Control-Allow-Origin: * when validation fails. Wildcard reflection bypasses credential isolation and conflicts with Access-Control-Allow-Credentials: true — the browser will reject the response entirely when both appear. For a full treatment of this trade-off, see Wildcard Risks & Mitigation.

Proxy and CDN Interaction

Dynamic CORS responses create cache partitioning requirements. When Access-Control-Allow-Origin varies by caller, every CDN and reverse proxy in the path must be configured to key its cache on Origin.

Vary: Origin is mandatory. Without it, a CDN caches the first response it sees for a given URL and serves that cached Access-Control-Allow-Origin header to all subsequent callers regardless of their origin. A caller from https://attacker.example.com may receive a response that includes a valid origin from a legitimate tenant.

Strip Origin on non-CORS routes. For API endpoints that do not need CORS, have the edge layer strip the Origin request header before it reaches your origin server. This prevents accidental reflection and eliminates the Vary overhead on routes that never emit CORS headers.

Forward validated origins upstream. When edge workers handle CORS validation before proxying to an upstream API, forward the validated origin via a custom header such as X-Validated-Origin. The upstream can trust this header for audit logging without re-running validation on every request.

CDN edge workers. When deploying origin validation in a Cloudflare Worker or similar edge function, keep the allowlist in a KV store with a short TTL rather than bundling it at deploy time. This allows tenant onboarding without redeployment, and the TTL ensures stale entries expire within minutes rather than hours.

DevTools and curl Verification Checklist

Use this checklist after deploying or modifying validation logic:

• Send a preflight from a browser with DevTools open: filter the Network tab by Options and confirm Access-Control-Allow-Origin in the response equals the request Origin exactly.
• Confirm Vary: Origin is present in all CORS responses (both preflight and actual request).
• Test with curl for a known-good origin:

  curl -si -X OPTIONS \
    -H "Origin: https://app.example.com" \
    -H "Access-Control-Request-Method: POST" \
    https://api.example.com/resource | grep -i "access-control\|vary"

• Test with curl for a non-allowlisted origin and confirm no Access-Control-Allow-Origin header appears:

  curl -si -X OPTIONS \
    -H "Origin: https://attacker.example.com" \
    -H "Access-Control-Request-Method: POST" \
    https://api.example.com/resource | grep -i "access-control"

• Test with curl for a credential-bearing request and confirm Access-Control-Allow-Credentials: true is present alongside the reflected origin:

  curl -si -H "Origin: https://app.example.com" \
    -H "Cookie: session=abc123" \
    https://api.example.com/resource | grep -i "access-control\|vary"

• Verify a CDN cache hit serves the same Access-Control-Allow-Origin as the original response — request the same URL twice from two different origins and confirm the headers differ (not cached cross-origin).
• Confirm Origin: null is rejected unless explicitly permitted (send Origin: null via curl and check the response).
• Check structured access logs to confirm validation results (allowed/rejected) are recorded alongside the origin value.

Common Mistakes

FAQ