CORS’ing the complexity: idempotent and caching meets Vary: Origin for CORS
So I spent a bit of time debugging something this am, and I thought I would share. Its super detailed, so feel free to gloss over.
I am using Istio. It magically takes the CORS origin and rewrites it. So if you do a:
GET / Origin: foo
then it will respond:
200 OK Access-Control-Allow-Origin: *
*if* its configured for ‘*’ policy.
Now, the problem is, I have two clients that are using OpenID Connect. They are fetching the keys for jwks validation. They run in the same browser. One of them does:
GET /keys Origin: app-1
the other does
GET /keys Origin: app-2
Unfortunately, the browser *caches* the 2nd response, returning the response app-1 got (with the wrong Access-Control-Allow-Origin) in it.
Why? Well, let’s dive into some specs. Here we find the answer.
If CORS protocol requirements are more complicated than setting `
*or a static origin, `
Vary` is to be used. [HTML] [HTTP] [HTTP-SEMANTICS] [HTTP-COND] [HTTP-CACHING] [HTTP-AUTH]
Huh. I’m supposed to add a ‘Vary’ header to these. But, sadly, I am not in control of these applications. What is one to do? RTFC for envoy?