Case Study: CORS Failure Caused by CDN Misconfiguration and Its Resolution

The author, a senior R&D manager at Ctrip, describes a situation where updating the Access-Control-Allow-Origin header to a specific origin caused client‑side CORS failures when the fetch API was used with credentials: 'include'.

Initially, the static resource service returned the same headers for all requests, including a wildcard * for Access-Control-Allow-Origin. After adding the credentials flag, browsers blocked the request because a wildcard origin is incompatible with credentialed requests.

Investigation revealed that the problem was not in the origin server code but in the CDN layer. Three CDN providers (B, W, and A) serve the resource; B behaved correctly, while W returned mismatched Access-Control-Allow-Origin and omitted the Vary header.

Because the Vary: Origin, Accept-Encoding header was missing, the CDN could not differentiate cached responses for different origins, leading to the wrong Access-Control-Allow-Origin being served to some clients.

The root cause was a CDN bug: when a 304 Not Modified response was returned, the CDN reused a cached response that still contained the wildcard origin, ignoring the correct header from the origin server.

To resolve the incident, the team shifted all traffic to the reliable B provider, worked with the W provider to fix the caching logic, and added a whitelist of resource domains for manual configuration.

Key lessons include the importance of comprehensive testing across all CDN providers after each release, strict adherence to HTTP standards, ensuring resource URLs are unique (e.g., using MD5 hashes), and maintaining clear communication with CDN vendors to handle caching anomalies.