Quelques en-têtes HTTP bien configurés réduisent drastiquement la surface d'attaque d'un site web — souvent pour un coût d'implémentation quasi nul. Ce guide explique les principaux et ce qu'ils protègent réellement.
HSTS indique au navigateur de ne plus jamais tenter de se connecter en HTTP simple à ce domaine pendant une durée donnée, même si l'utilisateur tape explicitement http:// dans la barre d'adresse. Sans cet en-tête, la première requête après une redirection HTTP→HTTPS reste vulnérable à une attaque de l'homme du milieu qui interceptait cette requête initiale non chiffrée.
Le paramètre preload va plus loin : il permet d'inscrire le domaine dans une liste intégrée aux navigateurs eux-mêmes, supprimant même cette première requête HTTP vulnérable. L'inscription est cependant difficile à annuler rapidement — à n'activer qu'une fois HTTPS pleinement stabilisé sur tous les sous-domaines.
La CSP est l'en-tête de sécurité le plus puissant contre les attaques XSS (injection de script). Elle définit une liste blanche des sources autorisées pour chaque type de ressource (scripts, styles, images, etc.) — un script injecté par un attaquant depuis une source non autorisée par la politique sera simplement bloqué par le navigateur, même si l'injection a techniquement réussi.
Une CSP mal configurée avec unsafe-inline ou unsafe-eval dans script-src perd une grande partie de son efficacité, puisqu'elle autorise alors l'exécution de scripts inline — le vecteur d'attaque XSS le plus courant.
Le clickjacking consiste à superposer une page légitime dans une <iframe> invisible sur un site malveillant, pour piéger un clic de l'utilisateur (par exemple, valider un achat ou une autorisation sans le savoir). Deux mécanismes protègent contre cela :
DENY interdit tout chargement en iframe, SAMEORIGIN ne l'autorise que depuis le même domaine.| En-tête | Rôle |
|---|---|
| X-Content-Type-Options: nosniff | Empêche le navigateur de réinterpréter un fichier comme un type différent de celui déclaré. |
| Referrer-Policy | Limite les informations envoyées dans l'URL d'origine lors de la navigation vers un autre site. |
| Permissions-Policy | Désactive les fonctionnalités du navigateur (caméra, micro, géolocalisation) non utilisées par le site. |
À l'inverse, X-XSS-Protection est aujourd'hui obsolète : les navigateurs modernes l'ignorent (et certains anciens l'utilisaient de façon qui pouvait elle-même introduire des failles) — il peut être retiré sans risque, une bonne CSP le remplace avantageusement.
Un cookie de session mal protégé est une cible de choix. Trois drapeaux devraient systématiquement accompagner un cookie sensible :
Strict ou Lax) : limite l'envoi du cookie lors d'une requête provenant d'un autre site, réduisant le risque de CSRF (falsification de requête inter-site).includeSubDomains, ce qui peut rendre certains sous-domaines inaccessibles s'ils ne servent pas encore de HTTPS valide.unsafe-inline partout) pour "faire marcher le site rapidement", perdant l'essentiel de la protection.Non — ces en-têtes réduisent des classes spécifiques d'attaques (XSS, clickjacking, downgrade HTTP) mais ne couvrent ni les failles applicatives (injection SQL, logique métier), ni la sécurité du serveur ou de l'infrastructure sous-jacente.
Dans les DevTools du navigateur (onglet Réseau), clique sur la requête principale du document et regarde les en-têtes de réponse. En ligne de commande : curl -I https://exemple.fr.
Oui, dans la mesure du possible — un réseau interne n'est pas à l'abri d'une compromission latérale (un poste infecté sur le même réseau, par exemple), et ces en-têtes restent une défense en profondeur peu coûteuse.
Selon la stack : dans la configuration du serveur web (Nginx, Apache), dans le code applicatif (middleware Express, decorators Django), ou via un CDN/reverse proxy qui les injecte en amont du serveur d'origine.
Outils similaires