(also see symfony/symfony-docs#7045)

http://symfony.com/doc/current/request/load_balancer_reverse_proxy.html and http://symfony.com/doc/current/components/http_foundation/trusting_proxies.html talk about trusting proxies, and http://symfony.com/doc/current/request/load_balancer_reverse_proxy.html#but-what-if-the-ip-of-my-reverse-proxy-changes-constantly in particular mentions AWS as an example.

AWS ELBs do not set a Forwarded header, making it necessary to follow the instructions at http://symfony.com/doc/current/request/load_balancer_reverse_proxy.html#my-reverse-proxy-sends-x-forwarded-for-but-does-not-filter-the-forwarded-header, but they also do not set an X-Forwarded-Host (only …-For, …-Port and …-Proto), which means, that for a very popular use case (running on AWS, or products that build on it, e.g. Heroku), applications would be vulnerable to spoofing of those headers.

My hunch is that a lot of developers don't realize that they need to explicitly distrust these headers, especially as the special case documentation and handling logic for Forwarded, unlike the other headers, has been introduced relatively recently.

I propose that out of the box, when a developer calls Request::setTrustedProxies(), no header names are trusted by default, and they must always be explicitly opted into using Request::setTrustedHeaderName(). That's only slightly more work, but means that the default is safe with an empty whitelist, and developers, having to investigate what headers really are being set in their environment, are much more likely to end up with valid settings that do not compromise application security.

/cc @fabpot, who asked me to open this issue (I may have time for a PR soon-ish)