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
OPTIONS only needs to be listed as an allowed method in the CORS configuration when the server wishes to allow clients to send actual (as opposed to preflight) OPTIONS requests, which is rare.
However, all CORS middleware produced by this library implicitly allow OPTIONS requests, even when OPTIONS isn't listed in their configuration's AllowedMethods field. As a result, those middleware unduly allow browser-based clients to send OPTIONS requests to the server.
Proof of concept
Consider the following server (borrowed from the README):
Note that OPTIONS is (but shouldn't be) listed in the response's Access-Control-Allow-Methods header:
HTTP/1.1 204 No ContentAccess-Control-Allow-Methods: OPTIONSAccess-Control-Allow-Origin: *Vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers-snip-
Therefore, preflight would succeed and the browser would (undesirably) proceed to send the client's actual OPTIONS request.
Remediation
// isMethodAllowed checks if a given method can be used as part of a cross-domain request
// on the endpoint
func (c *Cors) isMethodAllowed(method string) bool {
- if len(c.allowedMethods) == 0 {- // If no method allowed, always return false, even for preflight request- return false- }- if method == http.MethodOptions {- // Always allow preflight requests- return true- }
for _, m := range c.allowedMethods {
if m == method {
return true
The text was updated successfully, but these errors were encountered:
The proposed change is a breaking one (in terms of behaviour), but I don't expect that many CORS-aware servers wish to allow clients to send actualOPTIONS requests.
Problem
Contrary to popular belief,
OPTIONS
requests are CORS-preflight requests, andOPTIONS
only needs to be listed as an allowed method in the CORS configuration when the server wishes to allow clients to send actual (as opposed to preflight)OPTIONS
requests, which is rare.However, all CORS middleware produced by this library implicitly allow
OPTIONS
requests, even whenOPTIONS
isn't listed in their configuration'sAllowedMethods
field. As a result, those middleware unduly allow browser-based clients to sendOPTIONS
requests to the server.Proof of concept
Consider the following server (borrowed from the README):
Note that
cors.Default()
allowsGET
,HEAD
,POST
, but does not allowOPTIONS
.Start the server locally, then simulate a preflight request preceding an actual
OPTIONS
request by running the following command:Note that
OPTIONS
is (but shouldn't be) listed in the response'sAccess-Control-Allow-Methods
header:Therefore, preflight would succeed and the browser would (undesirably) proceed to send the client's actual
OPTIONS
request.Remediation
The text was updated successfully, but these errors were encountered: