\[~sebastien.gioria] I've added the CERT link, but I don't quite understand how this ties to the top 10. Can you point me in the right direction, please?
I had some code flagged because I use "127.0.0.1" as the default value when no other address had been supplied in a configuration file. Does it make sense to have this check treat the use of hard coded loopback addresses like 127.0.0.1 or ::1 a special case? From a information disclosure perspective I don't think those addresses provide much information to anyone, and the ability to be able to use them as a sane default for networked services without a config file makes sense to me.
Here is how I think this idea stands up to the effects this check hopes to have as defined in this ticket:
* a recompile is required if the address changes
This assumes that the value is not a default that can be overriden by a config file. Requiring a user to write a configuration file when listening on loopback for networked processes seems cumbersome to me (I would assume that a "default" config file example would use a loopback address such as 127.0.0.1 anyway).
* it forces the same address to be used in every environment (dev, sys, qa, prod)
See above.
* it places the responsibility of setting the value to use in production on the shoulders of the developer
See above.
* it allows attackers to decompile the code and thereby discover a potentially sensitive address
I do not think loopback addresses should be counted as sensitive information since there is no way to utilize them unless you already have local access to a machine of interest. The linked CERT page even uses the hostname "localhost" in the compliant solution regarding hard coded names and passwords (and the example regarding hard coded IP addresses uses a non-loopback address).
With this said I think using something like \https://docs.oracle.com/javase/10/docs/api/java/net/InetAddress.html#isLoopbackAddress() and skipping the warning if it comes out true is reasonable.
