Timeline for Vary: origin response header and CORS exploitation
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 13, 2022 at 22:00 | comment | added | jub0bs |
This response isn't quite correct. Vary: Origin does not instruct caches not to cache responses. Rather, it instructs caches to make the request's Origin header (if any) part of the cache key. If the cache respects the Vary header (some, like Cloudflare do not), the cache will cache responses; it will simply add a new entry for the response to a request with an Origin header that the cache hasn't seen before (or has since forgotten).
|
|
| Jul 19, 2019 at 16:08 | comment | added | Rice | @Arminius Would this attack not be mitigated by the proper cache-control directives? | |
| Jun 22, 2019 at 17:35 | comment | added | gaurav5430 | "should therefore not be served from cache for any other origin" - does it mean that if my frontend app runs on a different domain, and the browser makes requests to this endpoint on the frontend app's behalf, the responses would not get cached? even if Cache-Control headers are set correctly? | |
| Feb 24, 2017 at 5:52 | vote | accept | Shurmajee | ||
| Feb 23, 2017 at 14:28 | comment | added | Arminius | @Shurmajee Yes! | |
| Feb 23, 2017 at 7:58 | comment | added | Shurmajee | So this control would only prevent the cache poisoning attacks. There would still be risk associated with accepting arbitrary origins for cross domain data access. Is my understanding correct? | |
| Feb 17, 2017 at 21:46 | history | answered | Arminius | CC BY-SA 3.0 |