You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AllowOriginFunc, a field on cors.Options lets users specify a custom function of the following signature:
func (r*http.Request, originstring) bool
As indicated by relevant test cases, motivations for this feature include the desire to vary responses on the basis of the presence and/or value of some request headers (e.g. Authorization):
If you vary responses on the basis of the presence and/or value of some request header, HTTP indeed mandates that you list the name of that header in your responses' Vary header; doing this signals to caching intermediaries that the header in question should be part of the cache key. But because the predicate lacks a http.ResponseWriter parameter, it gives you no way of populating the Vary header as required! You have to remember to manually do so outside of the predicate, somehow. If you forget, as I believe most developers do, to adequately populate the Vary header, caching intermediaries are then liable to serve inappropriate (and possibly malicious) cached responses to your clients.
For example, in the test case mentioned above, the response to an authenticated request (one containing request header Authorization: secret) may well get cached and subsequently get served by Web caches as a response to unauthenticated requests... 😬
To rule out Web cache poisoning, AllowOriginFunc should provide users a way to populate the Vary header accordingly. Note that this would require changing the type of that field, which would be a breaking change.
The text was updated successfully, but these errors were encountered:
jub0bs
changed the title
AllowOriginFunc considered harmful (may lead to Web cache poisoning)
AllowOriginRequestFunc considered harmful (may lead to Web cache poisoning)
Dec 14, 2023
jub0bs
changed the title
AllowOriginRequestFunc considered harmful (may lead to Web cache poisoning)
AllowOriginFunc considered harmful (may lead to Web cache poisoning)
Dec 15, 2023
AllowOriginFunc
, a field oncors.Options
lets users specify a custom function of the following signature:As indicated by relevant test cases, motivations for this feature include the desire to vary responses on the basis of the presence and/or value of some request headers (e.g.
Authorization
):For this discussion, let's ignore
Authorization
header.Unfortunately, as I've written elsewhere,
AllowOriginFunc
opens the door to Web cache poisoning:For example, in the test case mentioned above, the response to an authenticated request (one containing request header
Authorization: secret
) may well get cached and subsequently get served by Web caches as a response to unauthenticated requests... 😬To rule out Web cache poisoning,
AllowOriginFunc
should provide users a way to populate theVary
header accordingly. Note that this would require changing the type of that field, which would be a breaking change.The text was updated successfully, but these errors were encountered: