Guide des ports HTTP : trafic web sur le port 80

HTTP est le protocole de requête et de réponse utilisé par les navigateurs, les API, les webhooks, les contrôles d'état et de nombreux services internes. Sur le port 80, le client se connecte via TCP, envoie une requête HTTP et reçoit des en-têtes et un corps de réponse sans établir de liaison TLS au préalable.

Le trafic n'étant pas chiffré, toute personne pouvant observer le chemin réseau peut voir les URL, les cookies, les en-têtes, les données de formulaire et le contenu des réponses, à moins que l'application n'ajoute sa propre protection. Pour les sites Web publics et les applications authentifiées, le port 80 devrait normalement rediriger vers HTTPS au lieu de diffuser directement du contenu privé.

Le port 80 est un simple HTTP. Le port 443 est HTTPS, ce qui signifie HTTP transporté dans une session chiffrée TLS. L'expérience utilisateur peut sembler similaire dans un navigateur, mais le modèle de sécurité est différent : HTTPS valide le certificat du serveur et crypte le trafic en transit.

La plupart des sites de production utilisent les deux ports ensemble. Le port 80 accepte les anciens liens, les défis de certificat et les premières requêtes du navigateur, puis envoie une redirection 301 ou 308 vers l'URL HTTPS sur 443. Après cela, HSTS peut indiquer aux navigateurs de préférer automatiquement HTTPS.

Gardez le port 80 ouvert lorsque vous avez besoin de redirections HTTP vers HTTPS, de défis Let's Encrypt HTTP-01, de vérifications de l'état de l'équilibreur de charge, de vérifications de l'origine CDN, de points de terminaison d'état internes simples ou de compatibilité avec des systèmes plus anciens qui ne peuvent pas démarrer directement sur HTTPS.

Fermez ou restreignez le port 80 lorsque le service est privé, lorsque tous les clients sont contrôlés et peuvent utiliser HTTPS directement, ou lorsque le simple HTTP crée une exposition inutile. Si vous le gardez ouvert, gardez le comportement étroit et prévisible : redirection, défi ou contrôle de santé plutôt qu'un accès complet à l'application.

Avant d'ouvrir TCP 80, vérifiez que le serveur Web, le proxy inverse, le contrôleur d'entrée, l'origine CDN ou l'équilibreur de charge prévu écoute sur la bonne interface. Décidez si le port 80 doit diffuser le contenu, rediriger vers 443, répondre aux contrôles d'état ou répondre uniquement aux chemins de validation des certificats.

Un vérificateur de port confirme l'accessibilité du réseau, mais il ne vous indique pas si votre chaîne de redirection, vos en-têtes de cache, votre routage d'hôte virtuel ou l'automatisation de vos certificats sont corrects. Testez à la fois le chemin TCP et le comportement HTTP avec un navigateur, curl et les journaux du serveur.

Sur Windows Server, exécutez IIS, Nginx, Apache, Caddy ou un autre serveur Web, liez le site à TCP 80 et autorisez le trafic HTTP entrant dans le pare-feu Windows Defender. Les serveurs cloud doivent également correspondre aux règles de pare-feu cloud ou de groupe de sécurité.

Sous Linux, configurez Nginx, Apache, Caddy, une publication de port de conteneur ou un contrôleur d'entrée pour écouter sur 80, puis autorisez TCP 80 dans ufw, firewalld, nftables, iptables ou le pare-feu du fournisseur. Les conteneurs et les services Kubernetes doivent publier ou acheminer le port au niveau de l'hôte, de l'équilibreur de charge ou de la couche d'entrée.

Sur macOS, le port 80 est le plus souvent utilisé pour le développement local ou les services de laboratoire. Les ports privilégiés peuvent nécessiter des autorisations élevées, et les règles locales de pare-feu ou de routeur déterminent toujours si d'autres machines peuvent accéder au service.

Commencez par une vérification du port externe par rapport au nom d'hôte public ou à l'adresse IP et au port 80. Si le résultat est ouvert, les clients distants peuvent établir une connexion TCP. Exécutez ensuite curl -I http://example.com pour inspecter les codes d'état, les redirections, les en-têtes du serveur et le comportement du cache.

Sur le serveur, vérifiez les écouteurs avec ss -tlnp, netstat, lsof ou PowerShell. Pour les proxys inverses et les déploiements cloud, comparez les règles de pare-feu hôte, les groupes de sécurité cloud, les écouteurs d'équilibrage de charge, les mappages de ports de conteneur et les journaux d'application, car n'importe quelle couche peut bloquer ou mal acheminer HTTP.

Si le port 80 s'affiche fermé, le serveur Web peut être arrêté, écoutant uniquement sur localhost, utilisant un port différent ou bloqué par le pare-feu de l'hôte. En cas d'expiration, les paquets peuvent être supprimés par un pare-feu cloud, une règle NAT de routeur, un filtre FAI, un paramètre CDN ou une politique de sécurité en amont.

Si le port 80 est ouvert mais que la page est erronée, inspectez l'ordre des hôtes virtuels, le routage de l'en-tête de l'hôte, les blocs de serveur par défaut, les proxys en amont, les mappages de conteneurs et les enregistrements DNS. Si les redirections sont en boucle, comparez les hôtes virtuels HTTP et HTTPS et assurez-vous que le proxy transmet correctement le schéma d'origine.

Utilisez le port 80 intentionnellement. Redirigez le trafic des applications vers HTTPS, évitez les informations d'identification et les données sensibles sur HTTP simple et conservez uniquement les points de terminaison qui doivent rester accessibles. Pour les sites publics, associez la redirection à des certificats valides sur 443 et HSTS après avoir confirmé que HTTPS est stable.

Enregistrez les requêtes sur le port 80, surveillez les chemins inattendus et supprimez les points de terminaison hérités qui n'ont plus besoin de HTTP simple. Si le port 80 est uniquement destiné à l'ACME ou aux vérifications de l'état, limitez les réponses à ces chemins afin que le service soit plus facile à raisonner et à surveiller.