Sécuriser son site avec les en-têtes HTTP : HSTS, CSP et Trusted Types

Lorsqu'on lance un audit Lighthouse sur un site, la catégorie « Bonnes pratiques » signale fréquemment des en-têtes HTTP de sécurité manquants. Ces en-têtes sont pourtant l'un des moyens les plus efficaces et les moins coûteux de durcir un site : quelques lignes de configuration suffisent à neutraliser des classes entières d'attaques. Cet article fait le tour des trois en-têtes que Lighthouse met le plus souvent en avant — HSTS, CSP et Trusted Types — et de la façon dont QuietCMS les met en œuvre.

HSTS : forcer le HTTPS

L'en-tête Strict-Transport-Security (HSTS) indique au navigateur de ne plus jamais charger le site en HTTP en clair. Une fois reçu, le navigateur convertit automatiquement toute requête http:// en https:// avant même de l'envoyer, ce qui ferme la porte aux attaques par interception (man-in-the-middle) et aux tentatives de rétrogradation de protocole.

La valeur recommandée combine une durée de validité d'un an avec deux directives optionnelles :

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

includeSubDomains étend la protection à tous les sous-domaines, et preload permet, après inscription, d'inclure le domaine dans la liste pré-chargée des navigateurs. Ces deux directives sont puissantes mais engageantes : il faut s'assurer que tous les sous-domaines sont bien servis en HTTPS avant de les activer.

CSP : reprendre le contrôle des scripts

La Content-Security-Policy (CSP) est la pièce maîtresse de la défense contre les injections de scripts (XSS). Elle déclare au navigateur quelles sources de contenu sont autorisées et bloque tout le reste. L'approche moderne repose sur un nonce régénéré à chaque requête, associé à strict-dynamic :

Content-Security-Policy: default-src 'self';
  script-src 'nonce-aB3xZ...' 'strict-dynamic';
  object-src 'none'; base-uri 'self';

Avec ce schéma, un script injecté par un attaquant ne portera jamais le bon nonce et sera donc refusé, même s'il parvient à s'insérer dans la page. QuietCMS génère cette politique côté serveur, à chaque chargement, pour que le nonce reste imprévisible.

Trusted Types : bloquer le XSS au niveau du DOM

Même avec une bonne CSP, certaines failles subsistent dans le code JavaScript lui-même : l'écriture directe dans innerHTML ou d'autres « puits » du DOM peut réintroduire du HTML malveillant. La directive require-trusted-types-for 'script' impose que ces points sensibles n'acceptent que des valeurs explicitement validées, fermant la dernière grande catégorie de XSS basée sur le DOM.

Cette protection est exigeante : certains scripts tiers (régies publicitaires, outils de mesure d'audience) ne sont pas encore compatibles. La bonne pratique consiste donc à la déployer d'abord en mode Report-Only, qui signale les violations sans rien bloquer, puis à passer en application stricte une fois le terrain dégagé.

Une sécurité pensée par défaut

Ces trois en-têtes ne sont qu'une partie de la stratégie de défense en profondeur de QuietCMS, qui couvre aussi la protection CSRF, la limitation de débit, le filtrage des accès et le chiffrement des données sensibles. L'objectif est qu'un site obtienne un bon score Lighthouse sans configuration manuelle, parce que les réglages sûrs sont activés d'origine.

Pour découvrir l'ensemble des mécanismes de protection et les articles associés, consultez la rubrique Sécurité.