La comunicación a través de 127.0.0.1 se puede considerar simplemente como otro mecanismo de IPC, pero que reutiliza los protocolos existentes. Al igual que la memoria compartida o los sockets o conductos de dominio UNIX, es una de las innumerables formas en que dos procesos pueden comunicarse en un solo sistema. Si confía en que los procesos de su sistema no se han visto comprometidos, puede confiar "a ciegas" en las conexiones que pasan por 127.0.0.1.
Si sabe que la dirección IP en el otro extremo de un socket TCP es 127.0.0.1, esto garantiza que el administrador del sistema ha configurado el firewall para redirigir esta conexión en particular, o que el otro extremo del socket TCP es un proceso que se ejecuta en la misma maquina Entonces, si confía en su máquina servidor como un todo, puede confiar en 127.0.0.1. Sin embargo, hay ventajas en no usar un socket TCP, para una defensa en profundidad.
Debe tener cuidado con la forma en que implementa la verificación localhost. Localhost es 127.0.0.1 hasta el día en que deja de serlo, por ejemplo, porque cambia a una versión de alguna biblioteca que usa IPv6 de forma predeterminada, o porque decide agregar algún tipo de proxy de reenvío a la mezcla para permitirle ejecutar el dos servicios en diferentes máquinas o contenedores. Si comienza a usar un proxy, tenga cuidado de verificar en el lugar correcto. Y, por supuesto, debe asegurarse de nunca alojar nada más que pueda ser dudoso en la misma máquina (aunque, ¿por qué lo haría en esos días de máquinas virtuales y contenedores?).
Saber que estás hablando con la misma máquina solo te dice que algunos el proceso en la misma máquina está en el otro extremo de la conexión. No te dice que es el proceso correcto. Bajo operación normal, presumiblemente, ambos procesos se están ejecutando. Pero si ocurre algo incorrecto, como que un proceso se bloquee después de quedarse sin memoria debido a un ataque de denegación de servicio, el puerto quedará libre para que otro proceso escuche. Y en cualquier momento, cualquier proceso local puede conectarse a un servidor en ejecución. Esto requiere que el atacante pueda ejecutar algún proceso localmente, pero podría ser un proceso sin privilegios que de otro modo no podría hacer mucho. Entonces, si bien confiar en 127.0.0.1 no es una vulnerabilidad, lo deja abierto a una escalada de privilegios.
Si puedes, usa un socket Unix en su lugar. Los sockets de Unix y TCP funcionan de la misma manera, excepto por especificar la dirección para conectarse o escuchar, por lo que no requeriría muchos cambios de código. Un socket Unix puede tener permisos, o puede ser creado por el supervisor principal, y nada más puede conectarse a él. Con un socket Unix, tiene la garantía de que no solo lo que está en el otro extremo del socket se ejecuta en la misma máquina, sino que es el proceso esperado. Esto solo lo deja vulnerable a una brecha de seguridad en el servicio de autenticación o el servicio principal, en lugar de una brecha en cualquier cosa que se ejecute en la misma máquina.