What did you do?

I studied the code in util/httputil/cors.go.

What did you expect to see?

Adequate protection against cache poisoning in Prometheus's implementation of CORS.

What did you see instead? Under which circumstances?

A Vary: Origin header is included only in responses to CORS requests, i.e. requests that contain an Origin header; see the relevant lines. A section of the Fetch standard points out that such an approach is problematic because it opens the door to cache-poisoning issues:

[...] consider what happens if Vary is not used and a server is configured to send [Access-Control-Allow-Origin](https://fetch.spec.whatwg.org/#http-access-control-allow-origin) for a certain resource only in response to a CORS request. When a user agent receives a response to a non-CORS request for that resource (for example, as the result of a navigation request), the response will lack [Access-Control-Allow-Origin](https://fetch.spec.whatwg.org/#http-access-control-allow-origin) and the user agent will cache that response. Then, if the user agent subsequently encounters a CORS request for the resource, it will use that cached response from the previous non-CORS request, without [Access-Control-Allow-Origin](https://fetch.spec.whatwg.org/#http-access-control-allow-origin).

As explained further down that section of the Fetch standard, only if responses to all requests contain either

Access-Control-Allow-Origin: *

or

Access-Control-Allow-Origin: <some-invariable-Web-origin>

may Origin not be listed in a Vary header in those responses.

Suggestion : because manual implementation of CORS is error-prone, consider relying on a dependable third-party CORS-middleware library instead.

System information

No response

Prometheus version

prometheus v3.0.0 (as well as earlier versions not listed here)

Prometheus configuration file

No response

Alertmanager version

No response

Alertmanager configuration file

No response

Logs

No response