En-têtes de sécurité HTTP : CSP, HSTS et le reste
Ce que font vraiment CSP, HSTS et les autres en-têtes de sécurité HTTP, comment les configurer, et quelle attaque chacun bloque, sans jargon technique.
Équipe rabbitclipPublié: 5 min de lecture
En bref
Les en-têtes de sécurité HTTP sont des règles qu'un serveur web ajoute à chaque réponse pour dire au navigateur comment se comporter. CSP limite les sources depuis lesquelles scripts et images peuvent se charger, HSTS force le navigateur à toujours utiliser une connexion chiffrée, et des en-têtes plus modestes comme X-Content-Type-Options et Referrer-Policy ferment des risques tout aussi réels. Aucun ne demande de code sur mesure ; quelques lignes dans la configuration du serveur ou du CDN suffisent.
Quand le site d'un cabinet d'avocats fait tourner un script publicitaire tiers sans CSP correctement configurée, ce script peut injecter presque n'importe quel code dans la page ; sur une page où une personne remplit un formulaire, ce risque n'a rien d'abstrait. Les en-têtes de sécurité limitent dès le départ ce qu'un tel script peut faire.
Qu'est-ce qu'un en-tête de sécurité HTTP, et comment fonctionne-t-il ?
Un en-tête de sécurité HTTP est une ligne d'instruction supplémentaire que le serveur envoie avec chaque réponse ; le navigateur la lit et restreint la page en conséquence. Les en-têtes ne changent pas le contenu de la page, seulement ce que le navigateur a le droit d'en faire.
Les ajouter ne demande pas d'écrire une nouvelle fonctionnalité ; quelques lignes dans la configuration de Nginx, Apache, Cloudflare ou d'un framework comme Next.js suffisent. Une fois bien configurés, ils partent automatiquement avec chaque requête de page.
Que fait vraiment Content-Security-Policy (CSP) ?
CSP définit depuis quelles adresses une page a le droit de charger scripts, images, polices et styles. Selon le guide des en-têtes HTTP de l'OWASP, CSP est le seul en-tête qui limite véritablement l'exécution d'un code déjà injecté dans une page ; c'est ce qui en fait l'une des défenses les plus efficaces contre les attaques par script inter-sites (XSS).
La partie difficile de la mise en place consiste à lister vraiment chaque ressource tierce utilisée par le site, l'analytics, un service de polices, un prestataire de paiement ; en oublier une casse une partie de la page. C'est pourquoi CSP tourne d'abord en mode rapport seul, on relit les journaux, avant de passer en mode restrictif.
Que garantit HSTS (Strict-Transport-Security) ?
HSTS indique au navigateur de ne plus jamais se connecter à un site en http:// non chiffré ; l'instruction est stockée côté navigateur, donc même si quelqu'un tape http dans la barre d'adresse, la connexion passe automatiquement en https. Cela empêche qu'une connexion soit rétrogradée en clair en cours de route, une attaque de type interception.
La configuration recommandée par MDN garde un max-age long, autour de deux ans, couvre aussi les sous-domaines, et peut être soumise à la liste de préchargement ; mais avant d'y entrer, chaque sous-domaine doit vraiment tourner en https, car en ressortir ensuite n'est pas simple.
Comment mettre en place un socle d'en-têtes de base
Pour un petit site institutionnel, les cinq en-têtes suivants sont un bon point de départ ; chacun ferme un risque différent.
- Content-Security-Policy : limite d'où scripts et ressources peuvent se charger
- Strict-Transport-Security : maintient la connexion chiffrée en permanence
- X-Content-Type-Options : nosniff, empêche le navigateur de deviner le type d'un fichier à tort
- Referrer-Policy : limite quelles informations de page fuient vers d'autres sites
- Permissions-Policy : restreint l'accès à des fonctions du navigateur comme la caméra ou la localisation
Tester les en-têtes et les garder sans erreur
Un en-tête mal configuré peut soit casser la page de façon visible, soit désactiver silencieusement une fonctionnalité ; les deux doivent être testés avant la mise en ligne. La console développeur du navigateur montre directement les violations de CSP ; quand une ressource est bloquée, la console la nomme et explique pourquoi.
Les changements devraient d'abord être essayés dans un environnement de test, puis sur une page en ligne à faible risque ; les déployer d'un coup sur tout le site risque de casser une intégration tierce inattendue.
Erreurs fréquentes
Les en-têtes de sécurité peuvent devenir un réglage qu'on met en place puis qu'on oublie ; cela mène à une rupture que personne ne remarque avant l'ajout d'une nouvelle intégration.
- assouplir CSP avec unsafe-inline, ce qui annule en grande partie l'intérêt de l'en-tête
- ajouter HSTS à la liste de préchargement sans l'avoir testé d'abord
- oublier de mettre à jour la liste CSP quand un nouveau script tiers est ajouté
- ne configurer les en-têtes que sur la page d'accueil et oublier le reste du site
Les en-têtes de sécurité HTTP ne changent pas l'apparence d'un site ; ils définissent ce que le navigateur a le droit d'en faire. Les mettre en place est un travail ponctuel, mais les maintenir à jour ne l'est pas. Un premier échange avec rabbitclip est un bon endroit pour vérifier quels en-têtes votre site possède réellement aujourd'hui.
Questions fréquentes
Les en-têtes de sécurité affectent-ils le SEO ?
Pas directement, mais des en-têtes comme HSTS qui forcent le HTTPS sont un signal positif indirect pour les moteurs de recherche qui valorisent les connexions sécurisées.
Mettre en place CSP peut-il casser un site qui fonctionne ?
Oui, en cas de mauvaise configuration. Tester d'abord en mode rapport seul et relire les journaux avant de passer en mode restrictif réduit ce risque.
Où configure-t-on ces en-têtes ?
Dans la configuration de Nginx, Apache, Cloudflare ou d'un framework comme Next.js ; la syntaxe diffère, la logique reste la même.
Un petit site a-t-il vraiment besoin de ces en-têtes ?
Oui. La taille n'y change rien ; tout site avec un formulaire, une page de connexion ou des scripts tiers fait face aux mêmes risques de base.
