In my own limited experience, it is quite common not have an untrusted Local Network, and only have a small set of trusted Reverse Proxies in front of the webserver(s).
Eg: I have my webserver sitting on machines 1-2 in a LAN, Haproxy/Varnish/Nginx on machines 3-4, and machines 5-999 used by other apps.
I don't want to automatically trust http requests coming in from those other machines to be properly filtering out spoofed original-ip http addresses.
I also generally don't want to spend too much time setting up firewalling rules to drop all http requests coming in from the other machines, as a random set of those could be monitoring/management systems which should be allowed to talk to the server - even bypassing the Reverse Proxy at times.

This used to be simple to manage when servers/vms where statically allocated, but now we live in a Docker/AWS world. But I presume that anybody who lives in a fully-dynamically-managed world has script-fu enough to be able to set up the trusted proxies with automatic reconfiguration upon infra deploy / update.

ps: sorry if this is OT. I just read the RFC, not the effective code change...

How would you implement that? I like the idea, but it should be explicit IMO.
So having local IP range by default in TRUSTED_PROXIES in .env, from the Flex recipe, would be great. Anything else, "hidden" in the code, I'm having mixed feelings.

Well, there is 3 solutions here:

1. the HttpFoundation always trusts the private IP range. Explicit configuration is adding more proxies to that list
2. the HttpFoundation trusts the private IP range by default but any explicit configuration would override the whole list
3. the private IP range is configured as part of the recipe only

As far as I understand their Ruby code, Rails is doing the first choice.

Doing the same as RoR would work for me.

Help wanted.

See symfony/recipes#651

I really not sure if we should trust local networks by default for the same reason @gggeek explained.

This kind of remind me of the old Elasticsearch broadcast discover (in the 1.x versions) that was problematic because people had their instances creating clusters with other people on the same local network on some hosting providers.

Since this option can lead to security concerns I think the default value should be secure in all cases.

As @stof reports, that's already the default in Ruby On Rails. I think that's a serious enough precedent to warrant us considering doing the same.

See https://api.rubyonrails.org/classes/ActionDispatch/RemoteIp.html

Note that I don't think this should be the default in Symfony core (I'm not sure it's worth the BC migration path we'll have to create)
That's why I'm proposing it as a recipe.

[ troll ] As @stof reports, that's already the default in Ruby On Rails. I think that's a serious enough precedent to warrant us doing the opposite. [ /troll ] :-P

Reading the Ruby-on-Rails middleware again, it is NOT enabled by default. But once enabled, it defaults to private IPs.

An alternative idea, similar to #33574: we could alias the special PRIVATE_IPS value to the private IP ranges.

Another idea: symfony/recipes#654

This does have potential security implications. Combined with poorly designed security controls - ex. firewalls that have access_control items with the only IP defined (unfortunately seen far too often even in this day and age).

Having private ranges trusted by default would increase the attack surface in Symfony installations where someone failed to pay attention to this and have LAN compromised boxes, have bad actors as LAN neighbors OR have some sort of shared hosting environment/whatnot weird network configuration.

I'd rather have a choice than unsafe default. It's probably just not worth the risk.