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 suggestion would be to

1. explicitly mention for the AWS case that both Forwarded and X-Forwarded-Host must be distrusted, or better yet
2. explicitly list known safe combinations for popular IaaS/PaaS systems and then
3. instruct users to carefully double-check what headers their platform in question supports, and distrust any that it does not.