Context.Scheme accepts malformed forwarded scheme values used by host redirects

[shblue21]

Issue Description

Context.Scheme() is documented as returning http or https, but X-Forwarded-Proto, X-Forwarded-Protocol, and X-Url-Scheme values are returned as-is.

This affects middleware.WWWRedirect() and middleware.NonWWWRedirect(), since both use c.Scheme() when building the Location header.

Example:

Host: app.example
X-Forwarded-Proto: //external.example

With middleware.WWWRedirect(), the response contains:

Location: //external.example://www.app.example/

Because the value starts with //, browsers resolve the Location as a network-path reference with host external.example.

This requires the redirect middleware to be enabled and the forwarded header to reach Echo. Context.Scheme() should ignore forwarded scheme values other than http and https, matching its documented return values.

Relevant code

In context.go:

if scheme := c.request.Header.Get(HeaderXForwardedProto); scheme != "" {
	return scheme
}
if scheme := c.request.Header.Get(HeaderXForwardedProtocol); scheme != "" {
	return scheme
}
if scheme := c.request.Header.Get(HeaderXUrlScheme); scheme != "" {
	return scheme
}

In middleware/redirect.go:

return true, scheme + "://www." + host + uri
return true, scheme + "://" + host[4:] + uri

Version/commit

This appears to affect both the current v5 branch and the supported v4 branch.

[aldas]

some historical notes why and when these were added:

• Get The HeaderXForwardedProto #941
• c3887eb

I think first remedy would be to check if these values from header are known acceptable values.

[aldas]

@shblue21, does #2953 look acceptable from your perspective?

[shblue21]

@aldas I left a short comment on #2953. The //external.example case looks blocked after that change, so this addresses the issue I reported.

Thank you for the quick fix.

[aldas]

allright , I will do a new release for v5 today and add that same fix to v4

[shblue21]

Thank you for handling this and the v4 backport.