Shouldn't the frontend remove the header if it's something that it would normally add? It's a major problem if your application is expecting a header to be set by the frontend web server, but is actually getting the value from the user agent.
The problem is, the using "HTTPS" HTTP header (that translates to "HTTP_HTTPS" environment variable in CGI terms) is a kludge. It should've been bare "HTTPS" variable in a same manner "REQUEST_ADDR" is, but someone didn't care much (or wasn't able to do things properly in early days) but shared a recipe that became so widespread, it's a nearly de-facto standard now. Or maybe this had evolved when TLS termination proxies were much more common, but due to laziness the recipe had eventually lost mandatory sanitization of X-Forwarded-For and HTTPS headers.
Still, if webserver is unaware of HTTPS (say, it had never ever had anything with TLS) it's not really webserver's fault it's not dropping some request header.
I believe it is known that some old reverse-proxies used this header before a standard solution emerged (X-forwarded-proto), Wordpress probably had to deal with this surprising behavior at some point.
Also, by naming a header "HTTPS", one could expect collision with a non-standard behavior: this is very common with HTTP/1.1.
In practice, with X-Forwarded-Proto, they don't, unless they can authenticate the downstream hop.
Let's say you configure your frontend server to set X-Foo and X-Bar fields. First, it should always send a header to the application indicating that it's messing with X-Foo and X-Bar, say "X-Added-By-My-Webserver: X-Foo, X-Bar". That way, the application can be sure that the frontend server is properly configured. Next, it should strip any X-Foo, X-Bar, and X-Added-By-My-Webserver, to prevent the client from being able to confuse the application with information the application expects to receive from the server.
This is still flaky because the frontend server could fail, and the user could send X-Added-By-My-Webserver, and so on, but if you must use in-band signalling, this seems like the safe route. Just blissfully adding a header is not enough to protect against evil or changing user agents.
Furthermore, it seems like a bad idea to make up your own header and not use an X- prefix.
In fact, we aren't talking about application headers. The HTTP RFC makes a distinction between application headers and hop-by-hop headers. There are mechanisms that proxies are required to implement, but they still don't.
For instance, a proxy must declare itself by appending its signature to a "Via" header - however most of them don't.
The RFC about forwarded HTTP extension is unclear about how a hop should deal with those headers, there is no one-size-fit-all situations: http://tools.ietf.org/html/rfc7239#section-8.1