The site is not querying localhost, the browser is.
I find it strange that we consider the error to lie in guile or redis or memcached or elastic search when clearly the browser is the security hole.
Why is it so?
Its only in combination with DNS that a browser can be tricked into sending requests where it didnt intend - but thats a problem of DNS.
So libnss or whatever library the browser uses sees lists.gnu.org and resolves that to 208.118.235.17 so browser initiates connection to that IP, but on subsequent requests, the name lists.gnu.org is changed to 127.0.0.1, how would a web-browser notice this, shouldnt the dns-library warn about this or just use a cache?
In any case, you can prevent it like this
iptables -A OUTPUT -d 127.0.0.0/8 -p tcp -m owner --uid-owner $YOUR_USER_ID_OF_BROWSER -m tcp -j REJECT --reject-with-tcp-reset
that is, if you run the browser under its own uid.
Let's say I visit google.com and it resolves to google's public Webserver. Your browser should be able to see whether the IP is in the public range (if I'm not mistaken you just checking that the IP is not an A, B, or C class IP, but don't quote me on that). If it is not a local IP (e.g. localhost, LAN, WAN), the browser should disallow all request to local IP addresses (Ajax queries, HTML frames, form requests) initiated by the initial page (google or whatever). It should work the other way around of course and I have never seen a use case where a public webpage relies on being able to query or send a request to my local network if this page is from the internet.
A normal HTTP redirect could be allowed because I think some routers rely on that to give the user a way to configure it (they tell the user to start configuring their router by going to config.manufacture.tld which displays some information and then issues a normal redirect to the default router IP).
Post request directly sent to the local network should be strictly forbidden, though. Why would I ever want to do that?
But still, whatever the protocol, the browser is the program that does something privacy sensitive by basically being used as a remote code execution tool, and it should not trust whatever information from whatever source, including name resolution regardless of the protocol. Therefore the browser trusting DNS when something obviously shady is going on (such as a resource ip changing to 127.0.0.1) is a bug in the browser, I think. I would feel safer, for instance, if the same origin policy would apply to the same TCP connection for instance, so that no amount of name or IP spoofing could work. Of course internet giants would not like it, but that would be their problem not mine, and really not so hard to solve.
127.0.0.1 accesses local servers that might be running code which is typically in development and insecure. There's nothing confusing about this.