Attaques sur l'en-tête Host : comprendre et se protéger
L'en-tête HTTP « Host » paraît anodin et purement technique. Pourtant, mal validé ou utilisé sans précaution, il devient un point d'entrée pour des attaques discrètes mais aux effets parfois sévères.
À quoi sert l'en-tête Host ?
L'en-tête « Host » est obligatoire dans une requête HTTP : il indique le domaine (et éventuellement le port) de la ressource demandée. Il permet au serveur de router la requête vers le bon site lorsque plusieurs domaines partagent une même adresse IP.
L'erreur fréquente consiste à croire que cet en-tête ne peut pas être manipulé par l'utilisateur. Or, comme tout champ d'une requête HTTP, il peut être modifié. S'il est mal validé ou réutilisé tel quel par l'application, il ouvre la voie à plusieurs attaques, un classique des tests d'intrusion.
Les attaques possibles
Réinitialisation de mot de passe détournée
Si le lien de réinitialisation de mot de passe est construit à partir du Host, l'attaquant peut faire pointer le lien vers son propre domaine et capter le jeton.
Empoisonnement de cache
Injecter un Host malveillant pour faire mettre en cache des réponses piégées, servies ensuite à d'autres utilisateurs.
Routage & contournement
Tromper la logique de routage ou de contrôle d'accès qui se fierait au Host pour distinguer les environnements.
Redirections ouvertes
Générer des redirections vers un domaine contrôlé par l'attaquant, support d'hameçonnage ou de vol de jeton.
Une confiance mal placée
Le fil rouge de ces attaques est une confiance injustifiée accordée à une donnée fournie par le client. Le cas le plus parlant est la réinitialisation de mot de passe : en détournant le Host, un attaquant peut recevoir le lien à la place de la victime et s'emparer du compte, un scénario voisin de ceux décrits dans le vol de compte. Ici encore, la règle est de ne jamais faire confiance aveuglément à l'entrée.
Le principe : ne pas se fier au Host fourni
Se protéger consiste à ne pas utiliser l'en-tête Host comme une valeur de confiance. On valide le Host contre une liste blanche de domaines autorisés, on s'appuie sur une URL de base configurée côté serveur (et non sur le Host de la requête) pour générer les liens absolus (notamment de réinitialisation), et on durcit la configuration du serveur et du cache. Ces points se vérifient lors d'un test d'intrusion applicatif.
Se protéger, étape par étape
Valider par liste blanche
N'accepter que les domaines explicitement autorisés et rejeter tout Host inattendu.
Utiliser une URL de base fixe
Générer les liens (dont la réinitialisation) à partir d'une configuration serveur, jamais du Host de la requête.
Durcir le serveur web
Configurer un hôte par défaut sûr et rejeter les requêtes au Host non reconnu.
Sécuriser le cache
Éviter que des en-têtes manipulables n'entrent dans la clé de cache, pour prévenir l'empoisonnement.
Maîtriser les redirections
Ne pas rediriger vers une destination dérivée d'un en-tête contrôlable par l'utilisateur.
Pourquoi se faire accompagner par BCIT ?
Des tests ciblés
Nous éprouvons concrètement le traitement du Host, notamment sur les parcours sensibles comme la réinitialisation.
Des correctifs simples
Liste blanche, URL de base, durcissement : des mesures claires et applicables.
Une vision d'ensemble
De la sécurité applicative aux audits, toute la chaîne.
Pas encore prêt à échanger ? Découvrez notre diagnostic cybersécurité →
Un en-tête anodin ne devrait pas vous coûter un compte
Prenons 15 minutes pour vérifier le traitement de l'en-tête Host dans vos applications et sécuriser les parcours sensibles.
Attaques sur l'en-tête Host : comprendre et se protéger
L'en-tête HTTP « Host » paraît anodin et purement technique. Pourtant, mal validé ou utilisé sans précaution, il devient un point d'entrée pour des attaques discrètes mais aux effets parfois sévères.
À quoi sert l'en-tête Host ?
L'en-tête « Host » est obligatoire dans une requête HTTP : il indique le domaine (et éventuellement le port) de la ressource demandée. Il permet au serveur de router la requête vers le bon site lorsque plusieurs domaines partagent une même adresse IP.
L'erreur fréquente consiste à croire que cet en-tête ne peut pas être manipulé par l'utilisateur. Or, comme tout champ d'une requête HTTP, il peut être modifié. S'il est mal validé ou réutilisé tel quel par l'application, il ouvre la voie à plusieurs attaques, un classique des tests d'intrusion.
Les attaques possibles
Réinitialisation de mot de passe détournée
Si le lien de réinitialisation de mot de passe est construit à partir du Host, l'attaquant peut faire pointer le lien vers son propre domaine et capter le jeton.
Empoisonnement de cache
Injecter un Host malveillant pour faire mettre en cache des réponses piégées, servies ensuite à d'autres utilisateurs.
Routage & contournement
Tromper la logique de routage ou de contrôle d'accès qui se fierait au Host pour distinguer les environnements.
Redirections ouvertes
Générer des redirections vers un domaine contrôlé par l'attaquant, support d'hameçonnage ou de vol de jeton.
Une confiance mal placée
Le fil rouge de ces attaques est une confiance injustifiée accordée à une donnée fournie par le client. Le cas le plus parlant est la réinitialisation de mot de passe : en détournant le Host, un attaquant peut recevoir le lien à la place de la victime et s'emparer du compte, un scénario voisin de ceux décrits dans le vol de compte. Ici encore, la règle est de ne jamais faire confiance aveuglément à l'entrée.
Le principe : ne pas se fier au Host fourni
Se protéger consiste à ne pas utiliser l'en-tête Host comme une valeur de confiance. On valide le Host contre une liste blanche de domaines autorisés, on s'appuie sur une URL de base configurée côté serveur (et non sur le Host de la requête) pour générer les liens absolus (notamment de réinitialisation), et on durcit la configuration du serveur et du cache. Ces points se vérifient lors d'un test d'intrusion applicatif.
Se protéger, étape par étape
Valider par liste blanche
N'accepter que les domaines explicitement autorisés et rejeter tout Host inattendu.
Utiliser une URL de base fixe
Générer les liens (dont la réinitialisation) à partir d'une configuration serveur, jamais du Host de la requête.
Durcir le serveur web
Configurer un hôte par défaut sûr et rejeter les requêtes au Host non reconnu.
Sécuriser le cache
Éviter que des en-têtes manipulables n'entrent dans la clé de cache, pour prévenir l'empoisonnement.
Maîtriser les redirections
Ne pas rediriger vers une destination dérivée d'un en-tête contrôlable par l'utilisateur.
Pourquoi se faire accompagner par BCIT ?
Des tests ciblés
Nous éprouvons concrètement le traitement du Host, notamment sur les parcours sensibles comme la réinitialisation.
Des correctifs simples
Liste blanche, URL de base, durcissement : des mesures claires et applicables.
Une vision d'ensemble
De la sécurité applicative aux audits, toute la chaîne.
Pas encore prêt à échanger ? Découvrez notre diagnostic cybersécurité →
Un en-tête anodin ne devrait pas vous coûter un compte
Prenons 15 minutes pour vérifier le traitement de l'en-tête Host dans vos applications et sécuriser les parcours sensibles.