La communication via 127.0.0.1 peut être considérée comme un autre mécanisme IPC, mais qui réutilise les protocoles existants. Tout comme la mémoire partagée ou les sockets ou canaux de domaine UNIX, c'est l'une des innombrables façons dont deux processus peuvent communiquer sur un seul système. Si vous pensez que les processus de votre système n'ont pas été compromis, vous pouvez faire confiance "aveuglément" aux connexions passant par 127.0.0.1.
Si vous savez que l'adresse IP à l'autre extrémité d'un socket TCP est 127.0.0.1, cela garantit que soit l'administrateur système a configuré le pare-feu pour rediriger cette connexion particulière, soit l'autre extrémité du socket TCP est un processus s'exécutant sur le même appareil. Donc, si vous faites confiance à votre machine serveur dans son ensemble, vous pouvez faire confiance à 127.0.0.1. Cependant, il y a des avantages à ne pas utiliser de socket TCP, pour une défense en profondeur.
Vous devez faire attention à la façon dont vous implémentez la vérification localhost. Localhost est 127.0.0.1 jusqu'au jour où il ne l'est plus, par exemple parce que vous passez à une version d'une bibliothèque qui utilise IPv6 par défaut, ou parce que vous décidez d'ajouter une forme de proxy de transfert au mélange pour vous permettre d'exécuter le deux services sur des machines ou conteneurs différents. Si vous commencez à utiliser un proxy, veillez à cocher au bon endroit. Et bien sûr, vous devez vous assurer de ne jamais héberger quoi que ce soit d'autre qui pourrait être douteux sur la même machine (mais pourquoi le feriez-vous à l'époque des VM et des conteneurs).
Savoir que vous parlez avec la même machine vous indique seulement que certains processus sur la même machine est à l'autre extrémité de la connexion. Cela ne vous dit pas que c'est le bon processus. En fonctionnement normal, vraisemblablement, les deux processus sont en cours d'exécution. Mais si quelque chose ne va pas, comme un processus qui plante après avoir manqué de mémoire en raison d'une attaque par déni de service, le port sera libre pour qu'un autre processus puisse l'écouter. Et à tout moment, n'importe quel processus local peut se connecter à un serveur en cours d'exécution. Cela nécessite que l'attaquant puisse exécuter certains processus localement, mais il peut s'agir d'un processus non privilégié qui, autrement, ne pourrait pas faire grand-chose. Ainsi, même si s'appuyer sur 127.0.0.1 n'est pas une vulnérabilité, cela vous expose à une élévation des privilèges.
Si vous le pouvez, utilisez plutôt un socket Unix. Les sockets Unix et TCP fonctionnent de la même manière, sauf pour spécifier l'adresse à laquelle se connecter ou écouter, de sorte que cela ne nécessiterait pas beaucoup de changement de code. Un socket Unix peut avoir des permissions, ou peut être créé par le superviseur parent, et rien d'autre ne peut s'y connecter. Avec un socket Unix, vous avez la garantie que non seulement ce qui se trouve à l'autre bout du socket s'exécute sur la même machine, mais que c'est le processus attendu. Cela vous rend uniquement vulnérable à une faille de sécurité dans le service d'authentification ou le service principal, plutôt qu'à une faille dans tout ce qui s'exécute sur la même machine.