Duplicate CORS Headers and Cache Problems: App, Proxy and CDN
By Ankit Jain · Updated
Choose one CORS policy owner, return a single origin permission, and prevent caches from mixing responses across origins.
When CORS works directly against the application but fails through a proxy, compare the response headers at both points. Two correct-looking configurations can combine into an invalid browser-facing response.
Pick one CORS owner
If the app returns Allow-Origin and Nginx adds another, the browser can see duplicate or combined values. Access-Control-Allow-Origin permits one value, not a list.
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Origin: *Remove the second writer rather than adding a third permission header. Verify application routes, OPTIONS, and gateway-generated errors because they may use different paths.
Varying by Origin requires cache care
When an approved-origin allowlist returns a different permission value per request, send Vary: Origin. Ensure the CDN honors that variation or includes the required origin distinction in its cache key. Merge Vary with existing values such as Accept-Encoding instead of overwriting them.
If the actual content differs by user or authentication, Vary: Origin alone does not make shared caching safe. Apply the endpoint’s appropriate private or no-store cache policy; do not cache personalized content as public.
Preflight caching is separate
Access-Control-Max-Age controls permission reuse in the browser’s dedicated preflight cache, subject to browser limits. A CDN may also cache OPTIONS if configured to do so; account for Origin, requested method, and requested headers. Do not assume clearing the CDN clears the browser’s preflight cache.
Verify the edge response
Capture raw headers from each approved origin and an unapproved origin. Repeat requests so cache hits are tested, then inspect the browser-facing result. Use a fresh browser context when checking a tightened preflight policy.
See invalid Allow-Origin and origin mismatch.