Certificat SSL/TLS et HTTPS : le rôle du certificat, de HSTS, de la CSP et des cookies

1. Comprendre le rôle du certificat pendant la visite

Quand un navigateur se connecte en HTTPS, TLS chiffre la communication. Le navigateur vérifie que le certificat présenté couvre le nom demandé, qu’il est encore valide et qu’il se rattache, par une chaîne de certificats, à une autorité en laquelle il a confiance. Le certificat contient les noms couverts, sa période de validité et les informations nécessaires pour construire cette chaîne.

Dressez la liste des noms publics : domaine principal, « www », sous-domaines de services comme la boutique, le support ou l’API. Pour chacun, notez le fournisseur qui gère le certificat et la façon dont il est renouvelé. Un CDN et le serveur d’origine ont souvent des certificats distincts, renouvelés séparément, et celui de l’origine est facile à oublier. Côté protocoles, l’ANSSI conseille, dans ses recommandations de sécurité relatives à TLS, de privilégier TLS 1.3, d’accepter TLS 1.2 et de ne plus utiliser SSLv2, SSLv3, TLS 1.0 ni TLS 1.1 ; la fiche TLS de l’OWASP aide à choisir et à entretenir le reste de la configuration. Pour partir d’un fait observé, notez le protocole effectivement négocié lors d’une connexion réelle.

Les durées de validité raccourcissent. Selon le calendrier adopté par le CA/Browser Forum, un certificat TLS public émis depuis le 15 mars 2026 ne peut pas dépasser 200 jours de validité ; ce sera 100 jours à partir du 15 mars 2027, puis 47 jours à partir du 15 mars 2029. Let’s Encrypt, de son côté, n’envoie plus d’e-mails de rappel avant expiration depuis le 4 juin 2025. Automatisez donc le renouvellement et ajoutez une surveillance indépendante de l’échéance, qui vous alerte si un renouvellement n’a pas eu lieu.

2. Voir comment les couches se complètent

Ces mécanismes se complètent sans se remplacer. Le certificat protège la connexion ; les en-têtes décrivent le comportement attendu pour une réponse donnée. Toutes les pages n’ont pas le même rôle : un article public, un espace client et un widget conçu pour être intégré ailleurs méritent chacun une politique adaptée. L’OWASP résume bien leur portée : bien choisis, ces en-têtes aident à prévenir des familles de problèmes comme le cross-site scripting (XSS), le détournement de clic (clickjacking) ou la fuite d’informations.

3. Construire la CSP à partir des ressources réellement utilisées

L’en-tête Content-Security-Policy indique au navigateur d’où la page peut charger scripts, styles, images, polices, connexions réseau et cadres. Son usage principal est de limiter l’impact d’une injection de script (XSS) ; le guide CSP de MDN rappelle qu’elle ne dispense pas d’assainir les entrées. Commencez par un inventaire des ressources en parcourant tout le trajet du visiteur : les ressources de paiement, d’authentification ou de support n’apparaissent souvent qu’après une interaction.

Testez ensuite la politique envisagée avec l’en-tête Content-Security-Policy-Report-Only : le navigateur ne bloque rien, mais signale chaque violation dans la console et, si vous l’avez configurée, à une adresse de rapport. Rattachez chaque message à sa ressource, décidez de la règle voulue, puis appliquez la politique une fois les parcours représentatifs passés en revue. Les deux en-têtes peuvent coexister pendant la transition. Attention : le mode rapport et la directive frame-ancestors ne fonctionnent qu’en en-tête HTTP, pas dans une balise <meta>.

Pour les scripts, la pratique recommandée par MDN est une politique dite stricte, fondée sur des nonces ou des empreintes (hashes) plutôt que sur une longue liste de domaines. Évitez 'unsafe-inline', qui annule une grande partie de l’intérêt de la CSP. Les scripts tiers qui en chargent d’autres ou utilisent du code inline compliquent parfois cette approche ; c’est un point à voir avec leurs éditeurs. Enfin, default-src sert de valeur de repli aux autres directives de chargement, mais pas à frame-ancestors : une politique default-src 'none' sans frame-ancestors laisse n’importe quel site intégrer la page. Un inventaire documenté facilite l’évaluation des ajouts futurs et justifie chaque autorisation.

4. Faire de HTTPS une habitude du navigateur

L’en-tête Strict-Transport-Security (HSTS) demande au navigateur de n’utiliser que HTTPS pour un hôte pendant une durée fixée en secondes par max-age, et de convertir automatiquement en HTTPS toute tentative ultérieure en HTTP. Le navigateur n’apprend cette politique que d’une réponse HTTPS valide : reçu en HTTP, l’en-tête est ignoré. La redirection de HTTP vers HTTPS ne doit donc pas le porter ; c’est la réponse HTTPS qui l’envoie. HSTS ne protège pas non plus la toute première visite, avant que le navigateur ait reçu l’en-tête. Autre conséquence à connaître : sur un hôte HSTS, le navigateur ne propose pas de passer outre une erreur de certificat, si bien qu’un certificat expiré rend le site inaccessible aux visiteurs qui le connaissent déjà.

L’ANSSI juge nécessaire de déployer HSTS dans ses recommandations pour la mise en œuvre d’un site web, en rappelant qu’un accès durable en HTTPS en est le préalable. Montez la durée par paliers (cinq minutes, une semaine, un mois) en vérifiant à chaque étape que rien ne casse, avant de passer à une durée longue, souvent un ou deux ans. L’option includeSubDomains étend la règle à tous les sous-domaines : reliez ce choix à l’inventaire des noms et assurez-vous qu’aucun sous-domaine, même interne, ne dépend encore de HTTP. Chaque sous-domaine a d’ailleurs intérêt à envoyer son propre en-tête, car un visiteur n’a peut-être jamais consulté le domaine principal. Pour revenir en arrière, max-age=0 désactive HSTS, à condition d’être reçu en HTTPS.

Le préchargement (preload) inscrit le domaine dans une liste intégrée aux navigateurs, ce qui couvre aussi la première visite. C’est un engagement à long terme. Le site hstspreload.org, qui reçoit les demandes d’inscription à cette liste, recommande toujours HSTS mais déconseille désormais le préchargement, puisque des navigateurs comme Chrome et Safari convertissent déjà automatiquement les navigations HTTP en HTTPS. Il précise qu’un retrait de la liste prend des mois et demande aux outils de ne pas ajouter preload par défaut. L’explication HSTS de MDN détaille ces options.

5. Adapter cookies et en-têtes au parcours

Un cookie de session permet au service de reconnaître une visite qui se poursuit ; ses attributs, décrits dans la documentation MDN de Set-Cookie, déterminent la façon dont il circule. Secure limite son envoi aux requêtes HTTPS (localhost excepté), sans pour autant le masquer à JavaScript. HttpOnly empêche les scripts de la page de lire le cookie, par exemple via document.cookie ; le navigateur continue pourtant de l’envoyer avec chaque requête correspondante, y compris celles déclenchées par JavaScript. Il ne chiffre pas le cookie et n’empêche pas une faille XSS : il limite le vol du cookie par ce biais.

SameSite contrôle l’envoi du cookie lors de requêtes intersites (Strict, Lax ou None), et un cookie en SameSite=None doit aussi porter Secure. Les navigateurs n’appliquent pas tous la même valeur par défaut : fixez-la explicitement, en fonction du parcours de connexion et des retours depuis un prestataire de paiement ou d’identité. Avec les préfixes de nom __Host- et __Secure-, le navigateur refuse tout cookie qui n’a pas été posé avec Secure depuis une origine HTTPS.

D’autres en-têtes précisent le traitement des contenus. X-Content-Type-Options: nosniff demande au navigateur de bloquer les scripts et feuilles de style servis avec un type MIME incorrect, et de ne pas deviner le type des autres réponses ; il suppose donc un Content-Type correct partout. Referrer-Policy détermine quelle partie de l’URL est transmise dans l’en-tête Referer ; l’OWASP conseille strict-origin-when-cross-origin. Contre le détournement de clic, la directive CSP frame-ancestors désigne les pages autorisées à intégrer la vôtre ; c’est aussi la protection que recommande l’ANSSI. X-Frame-Options: DENY ou SAMEORIGIN reste un repli pour les anciens navigateurs, mais la valeur ALLOW-FROM fait ignorer tout l’en-tête, et une déclaration dans une balise <meta> n’a aucun effet. Quant à X-XSS-Protection, il est obsolète : laissez-le absent ou à 0, et comptez sur la CSP.

La référence OWASP sur les en-têtes HTTP aide à choisir ces valeurs. Notez le rôle de chaque en-tête et l’endroit où il est posé (application, proxy ou CDN) pour que l’ensemble exprime une politique cohérente. Deux pièges classiques : sous nginx, add_header sans le paramètre always n’envoie l’en-tête que pour certains codes de réponse, si bien que les pages d’erreur en sont privées ; sous Apache, Header set et Header always set alimentent deux tables distinctes, ce qui peut produire des doublons.

6. Observer le résultat côté visiteur

Ouvrez une page avec les outils de développement du navigateur, onglet Réseau, et suivez les redirections jusqu’à la réponse finale. Examinez le certificat, les en-têtes et les cookies réellement reçus : vous reliez ainsi la configuration à l’expérience du visiteur et repérez quel service pose chaque réglage. En ligne de commande, curl -sI https://example.com/ affiche les en-têtes d’une réponse. Testez aussi l’adresse en http:// : selon le guide TLS de MDN, le port 80 doit rediriger vers la même ressource en HTTPS, d’abord sur le même nom d’hôte, et la page MDN sur HSTS conseille une redirection permanente, par exemple un code 301. Pour contrôler les en-têtes un par un avec les DevTools ou curl, avec des valeurs de départ sûres, consultez le guide pour vérifier les en-têtes de sécurité HTTP.

1. Visitez en HTTPS chaque nom public pris en charge, puis la même adresse en HTTP.
2. Notez les détails du certificat (émetteur, échéance) et la politique de la réponse finale.
3. Parcourez la connexion, la récupération de compte, le paiement intégré et les retours depuis des sites externes.
4. Relisez la console et la destination des rapports CSP.

Vérifiez aussi les pages d’erreur, en 404 comme en 500 : ce sont souvent elles qui perdent les en-têtes. Conservez un relevé daté de la configuration et le nom du responsable de chaque couche. Lors d’un changement d’hébergement ou d’intégration, rejouez le même parcours. Un déploiement planifié, avec la configuration précédente à portée de main, permet de revenir en arrière sans improviser, et la liste qui en résulte aide les personnes qui maintiendront le site ensuite à le prendre en main.

Pour vérifier dès maintenant les en-têtes d’un site, utilisez le vérificateur d’en-têtes de sécurité HTTP gratuit.

7. Garder la carte des protections à portée de main

Rassemblez au même endroit les noms publics, les responsables des certificats, les ressources chargées par le navigateur et les parcours importants. Pour un premier relevé, le snapshot gratuit de Sitelemetry exécute huit contrôles passifs sur une origine publique, sans inscription ; ce n’est pas un test d’intrusion. Côté TLS, il établit une connexion et relève la confiance de la chaîne, l’échéance (alerte à 30 jours ou moins) et le protocole négocié, sans dresser la liste de toutes les versions et suites prises en charge. Côté en-têtes, il lit la réponse finale de la page d’accueil, après au plus cinq redirections, et vérifie surtout la présence de CSP, de HSTS, d’une protection contre l’intégration en cadre (frame-ancestors ou X-Frame-Options), de nosniff et de Referrer-Policy, ainsi que HttpOnly et Secure sur les cookies de cette réponse ; SameSite n’est pas vérifié. Un max-age HSTS inférieur à 180 jours apparaît comme un point à revoir ; pendant une montée par paliers, c’est normal. La redirection de HTTP vers HTTPS n’est testée que si vous saisissez une adresse en http://, et le contrôle TLS est alors omis. Le résultat tient en un score, une note de durcissement distincte et jusqu’à trois signaux à examiner en premier.

Le guide pour tester la sécurité d’un site web montre comment ces couches s’articulent avec les comptes, les permissions et l’entretien courant.