Les en-têtes HSTS, COOP et Permissions-Policy expliqués

Un rapport d'audit de sécurité mentionne presque toujours trois en-têtes que le site devrait envoyer et qu'il n'envoie pas. Les noms sont peu engageants, les documentations officielles sont écrites pour des spécialistes, et la tentation est grande de copier une ligne de configuration trouvée sur un forum sans comprendre ce qu'elle fait. Cette approche fonctionne parfois et elle casse le site le reste du temps, généralement sur une fonctionnalité utilisée par une minorité de visiteurs, ce qui retarde d'autant la découverte du problème. Nous reprenons donc ces trois en-têtes un par un, en expliquant ce qu'ils protègent, contre quoi, et comment les activer sans provoquer d'incident.

Ce qu'est un en-tête de réponse et pourquoi cela compte

Lorsqu'un navigateur demande une page, le serveur ne renvoie pas seulement le contenu : il renvoie d'abord une série de lignes d'information que le visiteur ne voit jamais. Ces lignes indiquent le type de document, sa taille, sa durée de conservation en cache et un certain nombre de consignes que le navigateur est censé respecter. Les en-têtes de sécurité appartiennent à cette dernière catégorie : ils demandent au navigateur d'appliquer des restrictions supplémentaires à la page qu'il vient de recevoir. Le principe général de cette famille de protections, dont le passage au protocole sécurisé constitue le préalable, est développé dans notre article sur les moyens de renforcer la sécurité d'un site en HTTPS.

La particularité de ce mécanisme est qu'il repose entièrement sur la coopération du navigateur. Le serveur ne peut rien imposer, il peut seulement demander, et un navigateur ancien qui ne connaît pas l'en-tête l'ignorera purement et simplement. Cette caractéristique rassure autant qu'elle limite : ajouter un en-tête inconnu d'un vieux navigateur ne casse rien, mais ne protège pas non plus les visiteurs qui l'utilisent. Dans la pratique, les navigateurs actuels reconnaissent tous les en-têtes présentés ici, ce qui couvre la quasi totalité du trafic réel d'un site professionnel.

Ces en-têtes se posent au niveau du serveur web ou du réseau de diffusion, jamais dans le contenu de la page. Sur un hébergement mutualisé, le fichier de configuration du répertoire permet généralement de les ajouter. Sur un serveur dédié ou un conteneur, la configuration du serveur web s'y prête mieux et évite d'avoir à répéter la déclaration. Sur un site placé derrière un service de diffusion, l'interface de ce service propose presque toujours un formulaire dédié, ce qui constitue la solution la plus simple et la plus fiable.

Vérifier ce qui est réellement envoyé se fait en quelques secondes depuis les outils de développement du navigateur, dans l'onglet réseau, en sélectionnant la première requête de la page. Des services en ligne produisent également un rapport complet à partir de l'adresse du site. Cette vérification doit être faite après chaque modification, car une configuration correcte sur le papier peut être écrasée par un autre fichier de configuration, par un module d'optimisation ou par le service de diffusion lui même.

HSTS, ou la promesse de ne jamais revenir en arrière

Le premier en-tête concerne le protocole sécurisé. Un site correctement configuré redirige déjà les visiteurs qui arrivent en clair vers la version chiffrée, ce qui semble suffisant. Le problème tient à cette toute première requête : elle part en clair, elle peut être interceptée, et la redirection qui suit peut être détournée. La fenêtre est courte, elle existe, et elle suffit à un attaquant placé sur le même réseau que le visiteur, dans un lieu public par exemple. Cet en-tête sert précisément à supprimer cette fenêtre.

Le mécanisme est le suivant : lors d'une visite en HTTPS, le serveur indique au navigateur que le site ne doit plus jamais être contacté en clair, pendant une durée donnée. Le navigateur enregistre cette consigne et, lors des visites suivantes, il transforme lui même toute adresse en clair vers la version sécurisée avant même d'envoyer la moindre requête. La redirection ne part plus du serveur, elle est effectuée localement, ce qui ne laisse aucune prise. La durée s'exprime en secondes et la valeur usuelle correspond à un an, soit trente et un millions de secondes environ.

Deux options complètent la déclaration. La première étend la consigne à tous les sous domaines, ce qui protège les espaces annexes que l'on oublie souvent de configurer. La seconde demande l'inscription du domaine dans une liste intégrée directement aux navigateurs, ce qui protège dès la toute première visite, sans attendre qu'un premier passage ait eu lieu. Cette seconde option est puissante et elle demande beaucoup de prudence, puisque le retrait de cette liste prend plusieurs mois.

La règle de mise en place est donc la progressivité. On commence par une durée courte, de l'ordre de quelques minutes, le temps de vérifier que tout fonctionne. On passe ensuite à quelques jours, puis à un an une fois la certitude acquise. L'extension aux sous domaines n'intervient qu'après avoir vérifié que chacun d'eux dispose bien d'un certificat valide, faute de quoi ils deviendront inaccessibles. L'inscription dans la liste intégrée se décide en dernier, en connaissance de cause, et se justifie surtout pour les sites manipulant des données sensibles.

COOP, ou l'isolement des fenêtres ouvertes

Le deuxième en-tête traite un sujet moins intuitif : les relations entre une page et les fenêtres qu'elle ouvre ou qui l'ouvrent. Par défaut, une page qui en ouvre une autre conserve une référence vers elle, et réciproquement. Cette référence permet des échanges légitimes, comme une fenêtre de paiement qui informe la page d'origine du résultat d'une transaction. Elle ouvre aussi la porte à des manipulations, notamment lorsqu'un site tiers ouvre le vôtre et conserve la possibilité d'agir dessus. Le contexte plus large de ce type de failles est présenté dans notre article sur les failles de sécurité d'un site internet.

Cet en-tête permet de déclarer que la page doit être placée dans un groupe de navigation isolé, sans lien avec la fenêtre qui l'a ouverte. La valeur la plus stricte coupe toute relation dans les deux sens. Une valeur intermédiaire conserve la relation lorsque la fenêtre appelante appartient au même domaine, ce qui préserve les usages internes tout en coupant les liens externes. C'est cette valeur intermédiaire qui convient à la grande majorité des sites, car elle apporte l'essentiel du bénéfice sans risque fonctionnel notable.

Le second intérêt de cet en-tête est moins connu et souvent plus déterminant. Combiné à un en-tête voisin qui contrôle l'intégration de ressources externes, il permet à la page d'accéder à des fonctions de mesure de précision que les navigateurs ont désactivées par défaut à la suite de vulnérabilités matérielles. Pour un site classique, cet aspect ne présente aucun intérêt. Pour une application manipulant des calculs lourds ou du traitement de médias, il devient une condition d'accès à des capacités indispensables.

Les risques de casse concernent essentiellement les intégrations qui reposent sur des fenêtres surgissantes. Une authentification externe, un module de paiement, un partage vers un réseau social : tous ces mécanismes utilisent une fenêtre ouverte qui renvoie ensuite une information à la page d'origine. Appliquer la valeur la plus stricte sans vérification casse ces parcours de façon silencieuse, l'utilisateur restant simplement bloqué sur un écran d'attente. La bonne méthode consiste à recenser ces intégrations, à choisir la valeur intermédiaire par défaut, puis à tester chaque parcours de bout en bout avant de généraliser.

Permissions-Policy, ou le contrôle des fonctions du navigateur

Le troisième en-tête agit sur un terrain différent : il détermine quelles fonctions matérielles et logicielles du navigateur la page a le droit d'utiliser. Caméra, microphone, position géographique, capteurs de mouvement, paiement intégré, plein écran : chacune de ces fonctions peut être autorisée ou interdite explicitement. Une politique complète et restrictive dépasse largement le contrôle offert par la déclaration de sources autorisées, dont le rôle est détaillé dans notre article sur la définition de la CSP.

L'intérêt principal ne réside pas dans la protection de la page elle même, qui n'utilise généralement aucune de ces fonctions, mais dans le contrôle de ce que les contenus intégrés peuvent faire. Une publicité, un lecteur vidéo, une carte, un formulaire externe s'exécutent dans un cadre qui hérite par défaut d'une partie des permissions de la page hôte. Déclarer explicitement que personne n'a le droit d'accéder au microphone ferme cette possibilité de façon nette, sans dépendre du bon comportement du fournisseur.

La syntaxe consiste à énumérer les fonctions avec la liste des origines autorisées. Une liste vide interdit la fonction à tout le monde, y compris à la page elle même. Un mot clé désigne la page d'origine, et une adresse précise autorise un contenu intégré particulier. La déclaration peut donc être très fine, ce qui permet par exemple d'autoriser le plein écran uniquement pour le lecteur vidéo effectivement utilisé sur le site.

La bonne pratique consiste à partir d'une politique refusant tout, puis à réactiver au cas par cas ce dont le site a réellement besoin. Cette approche demande de recenser les usages, ce qui constitue un exercice utile en soi : beaucoup d'équipes découvrent à cette occasion que certaines fonctions étaient accessibles sans raison. Les risques de casse sont réels mais localisés et faciles à diagnostiquer, le navigateur signalant clairement dans sa console qu'une fonction a été refusée par la politique.

L'ordre de mise en place et la méthode

Ces trois en-têtes n'ont ni le même niveau de risque ni le même bénéfice immédiat, ce qui suggère un ordre de traitement. La politique de permissions vient en premier, car elle est la moins risquée : commencer par interdire les fonctions manifestement inutilisées, comme le microphone et les capteurs de mouvement sur un site vitrine, ne présente aucun danger. Ce premier pas familiarise l'équipe avec la manipulation des en-têtes et avec la procédure de vérification, ce qui sert pour la suite.

La consigne de protocole sécurisé vient ensuite, avec la progression de durée décrite plus haut. Elle est extrêmement simple à poser et son seul danger réside dans l'irréversibilité pratique : une fois qu'un navigateur a enregistré une consigne d'un an, il n'existe aucun moyen d'atteindre les visiteurs concernés pour la révoquer. C'est précisément pour cela que la montée progressive n'est pas une précaution excessive mais une nécessité.

L'isolement des fenêtres arrive en dernier, parce qu'il est le plus susceptible de casser un parcours métier. Le recensement préalable des intégrations utilisant des fenêtres ouvertes constitue l'essentiel du travail, la déclaration elle même prenant quelques secondes. Sur un site marchand, cette vérification doit inclure le tunnel de paiement complet, jusqu'à la page de confirmation, avec chaque moyen de paiement proposé.

Dans tous les cas, la mise en place se fait d'abord sur un environnement de préproduction, puis en production sur une durée d'observation courte. Surveiller les journaux d'erreur du navigateur et les taux de conversion pendant les jours qui suivent permet de détecter une casse silencieuse. Une régression sur un parcours minoritaire peut sinon passer inaperçue plusieurs semaines, ce qui coûte bien plus cher que le temps consacré à la vérification.

Les erreurs les plus fréquentes

La première consiste à copier une configuration complète trouvée en ligne et à la coller sans adaptation. Ces configurations sont écrites pour un contexte précis, souvent une application n'ayant aucune intégration externe, et elles interdisent des choses dont le site a besoin. Le résultat est un site partiellement cassé, avec des symptômes dispersés que personne ne relie à la modification effectuée trois semaines plus tôt. Prendre les en-têtes un par un, en comprenant ce que chacun fait, coûte une heure de plus et évite plusieurs journées de diagnostic.

La deuxième erreur consiste à poser les en-têtes à plusieurs endroits, ce qui produit des déclarations en double ou contradictoires. Un serveur web, un module d'optimisation, un service de diffusion et le code applicatif peuvent chacun ajouter leur version. Selon les cas, le navigateur retient la première valeur, la dernière, ou considère la déclaration comme invalide et l'ignore entièrement. La règle est de choisir un seul point de déclaration et de vérifier ensuite ce qui arrive réellement au navigateur, sans se fier à la configuration écrite.

La troisième erreur tient à l'oubli des sous domaines et des environnements annexes. Un espace de préproduction, un site de documentation, un serveur de fichiers hérités du protocole en clair : chacun devient inaccessible dès que la consigne de sécurité est étendue à tous les sous domaines. Le recensement complet des noms utilisés, y compris ceux qui ne servent qu'en interne, doit précéder cette extension. Une adresse interne oubliée peut bloquer une équipe entière du jour au lendemain.

La dernière erreur est de considérer le sujet comme réglé une fois les en-têtes posés. Les intégrations évoluent, un nouvel outil est ajouté, un prestataire change de mécanisme d'authentification, et une politique restrictive devient un obstacle. Inscrire la vérification des en-têtes dans la liste des contrôles effectués avant chaque mise en ligne importante évite cette dérive. Un contrôle automatisé, lancé après chaque déploiement, remplit ce rôle pour un coût négligeable.

Ce que ces en-têtes ne font pas

Il faut être clair sur les limites de ces protections, car les rapports d'audit qui les recommandent laissent parfois croire qu'elles règlent la question de la sécurité. Ces en-têtes ne protègent pas contre une vulnérabilité dans le code du site, contre un mot de passe faible, contre une extension compromise ou contre un accès administrateur mal protégé. Ils réduisent la surface d'attaque côté navigateur, ce qui est utile, et ils ne remplacent en rien la sécurisation du serveur et de l'application.

Ils n'améliorent pas non plus le référencement de façon directe. Aucun moteur ne classe mieux un site parce qu'il envoie une politique de permissions restrictive. L'effet indirect existe, puisqu'un site compromis perd sa visibilité très rapidement, mais il ne faut pas présenter ces mesures comme un levier de positionnement. Les vendre sous cet angle décrédibilise le travail réel qu'elles accomplissent.

Enfin, ils ne dispensent pas d'une politique de mise à jour rigoureuse, de sauvegardes testées et d'une surveillance des accès. Ces trois fondamentaux traitent les scénarios les plus fréquents de compromission d'un site professionnel, très loin devant les attaques que les en-têtes bloquent. L'ordre des priorités doit refléter cette réalité : poser les en-têtes prend une heure et mérite d'être fait, remettre à niveau les fondamentaux prend plus de temps et protège davantage.

Nous ne sommes pas experts en sécurité offensive et cet article ne constitue pas un audit. Sur un site manipulant des données de santé, des données bancaires ou un volume important de données personnelles, l'accompagnement par un spécialiste reste indispensable. Les éléments présentés ici visent à permettre une discussion informée avec ce spécialiste, pas à la remplacer.