En-têtes sécurisés

Definition

Les en-têtes sécurisés sont des en-têtes de réponse HTTP qui indiquent aux navigateurs comment gérer divers aspects liés à la sécurité du contenu Web. Il s'agit notamment des en-têtes HSTS, CSP, X-Frame-Options et autres. Des en-têtes de sécurité correctement configurés offrent une couche de défense supplémentaire contre diverses attaques, notamment le XSS, le clickjacking et les attaques par rétrogradation de protocole.

Vous recherchez peut-être également :

Politique de sécurité du contenu (CSP) Voir la définition HSTS (Sécurité de transport stricte) Voir la définition X-Content-Type-Options Voir la définition

Ce que sont les en-têtes de sécurité

Les en-têtes de sécurité sont des en-têtes de réponse HTTP qu'un serveur envoie pour indiquer au navigateur comment traiter le contenu et les connexions d'une page. Plutôt que de résider dans le corps de la page, ils configurent les propres défenses du navigateur : Content-Security-Policy restreint les scripts et ressources pouvant se charger, Strict-Transport-Security impose le HTTPS, X-Frame-Options (ou frame-ancestors de la CSP) bloque l'inclusion dans des cadres, X-Content-Type-Options empêche le MIME sniffing, et Referrer-Policy ainsi que Permissions-Policy limitent les données et les API qu'une page expose. Chaque en-tête cible une catégorie d'attaque précise. Comme le navigateur les applique, ils ajoutent une défense en profondeur par-dessus la validation côté serveur et la logique applicative, et leur déploiement est généralement peu coûteux au niveau du serveur web, du CDN ou de l'edge.

Pourquoi la configuration des en-têtes compte

Des en-têtes de sécurité absents ou faibles laissent des catégories d'attaques connues ouvertes, même lorsque le code de l'application est sain. Sans HSTS, un utilisateur peut être rétrogradé vers du HTTP en clair et intercepté ; sans restriction d'inclusion dans des cadres, la page peut être détournée par clickjacking ; sans Content Security Policy, un script injecté s'exécute librement. Les en-têtes sont un contrôle peu coûteux à forte couverture, c'est pourquoi ils figurent dans les audits de conformité et les scanners automatisés. Mais ils ne constituent qu'une base : une CSP permissive qui conserve unsafe-inline, ou un en-tête HSTS sans includeSubDomains, procure un faux sentiment de sécurité. Le détail de la configuration importe autant que la présence, et les en-têtes protègent le document first-party, non le comportement des scripts tiers qu'il charge.

Renforcer les en-têtes, et le rôle plus restreint de cside

Définissez une Content-Security-Policy stricte (fondée sur un nonce ou un hachage, sans unsafe-inline), un HSTS avec un long max-age et includeSubDomains, X-Content-Type-Options: nosniff, une restriction d'inclusion dans des cadres et une Referrer-Policy stricte ; testez avec un scanner d'en-têtes et déployez d'abord la CSP en mode report-only. Rappelez-vous que les en-têtes peuvent être retirés ou affaiblis en aval, car des extensions de navigateur malveillantes et du code injecté peuvent les supprimer côté client. Le rôle de cside est plus restreint et complémentaire : il gère et surveille la CSP, et en faisant transiter les scripts tiers par un méthode Script tout en analysant la charge utile, il détecte les comportements de script malveillants que les en-têtes seuls autorisent, en conservant des traces forensiques utiles pour les exigences PCI DSS 6.4.3 et 11.6.1.

Définition

Quels en-têtes de sécurité comptent le plus pour un site web typique ?

Une Content-Security-Policy stricte, Strict-Transport-Security, X-Content-Type-Options réglé sur nosniff et un contrôle d'inclusion dans des cadres tel que X-Frame-Options ou frame-ancestors de la CSP couvrent les risques les plus lourds de conséquences : injection de script, rétrogradation de protocole, confusion MIME et clickjacking. Referrer-Policy et Permissions-Policy sont des ajouts précieux pour limiter les fuites de données et restreindre les API puissantes du navigateur.

Définition

Les en-têtes de sécurité peuvent-ils être supprimés après que le serveur les a définis ?

Oui. Des proxys, des CDN mal configurés et surtout des extensions de navigateur malveillantes ou surprivilégiées peuvent retirer ou modifier les en-têtes de réponse avant ou après qu'ils atteignent le navigateur. C'est pourquoi les en-têtes constituent une couche de défense plutôt qu'une garantie, et pourquoi il reste important de surveiller ce que les scripts font réellement dans le navigateur.

Got more questions

Talk to a security expert

We answer client-side security questions every day. Bring yours.

Book a demo

Browse all terms