Summary
The gateway falls back to Access-Control-Allow-Origin: * if CORS header generation throws. That converts a restrictive allowlist design into permissive wildcard CORS on the error path.
Evidence
server/gateway.ts#L426-L431 wraps getCorsHeaders(request) in a try/catch and, on exception, sets corsHeaders = { 'Access-Control-Allow-Origin': '*' }.
- The normal CORS path is explicitly allowlist-based in
server/cors.ts, so the catch block materially broadens access instead of failing closed.
Why this matters
- Security controls should fail closed, not open.
- Any regression, malformed header edge case, or future exception inside CORS handling can silently broaden cross-origin readability for responses that were supposed to stay origin-restricted.
- This is especially risky in a gateway that fronts premium, user, and intelligence-adjacent endpoints.
Attack or failure scenario
A deploy introduces a parsing bug or an unexpected request shape that causes getCorsHeaders() to throw for some request path. Instead of rejecting or omitting CORS headers, the gateway emits wildcard ACAO, allowing arbitrary origins to read responses that normally rely on the allowlist.
Root cause
The defensive fallback prioritizes availability over origin enforcement and treats CORS generation failure as a reason to widen policy rather than reject the request.
Recommended fix
- Replace the wildcard fallback with fail-closed behavior.
- Return a 4xx/5xx error or omit CORS headers when origin validation cannot be completed safely.
- Add tests for malformed origin/request cases to prove CORS errors do not widen access.
- Log CORS-generation failures with request context that excludes secrets.
Acceptance criteria
- CORS header generation failures no longer emit wildcard ACAO.
- Error-path behavior is explicitly tested and fails closed.
- Gateway logs make CORS exceptions observable without exposing sensitive headers.
Suggested labels
- security
- bug
- production-readiness
Severity
High — an exception in origin handling can silently broaden cross-origin readability beyond the intended allowlist.
Confidence
Confirmed — the wildcard fallback is explicit in the gateway error path.
Summary
The gateway falls back to
Access-Control-Allow-Origin: *if CORS header generation throws. That converts a restrictive allowlist design into permissive wildcard CORS on the error path.Evidence
server/gateway.ts#L426-L431wrapsgetCorsHeaders(request)in atry/catchand, on exception, setscorsHeaders = { 'Access-Control-Allow-Origin': '*' }.server/cors.ts, so the catch block materially broadens access instead of failing closed.Why this matters
Attack or failure scenario
A deploy introduces a parsing bug or an unexpected request shape that causes
getCorsHeaders()to throw for some request path. Instead of rejecting or omitting CORS headers, the gateway emits wildcard ACAO, allowing arbitrary origins to read responses that normally rely on the allowlist.Root cause
The defensive fallback prioritizes availability over origin enforcement and treats CORS generation failure as a reason to widen policy rather than reject the request.
Recommended fix
Acceptance criteria
Suggested labels
Severity
High — an exception in origin handling can silently broaden cross-origin readability beyond the intended allowlist.
Confidence
Confirmed — the wildcard fallback is explicit in the gateway error path.