Sécurité d'un site web : HTTPS, HSTS, CSP expliqués simplement
Une dizaine de consignes, invisibles pour vos visiteurs, protègent votre site et ceux qui le consultent. Voici à quoi elles servent, illustrées sur mon propre site, et comment l'Observatory de Mozilla les note.
Un site vitrine paraît sans enjeu : quelques pages, un formulaire de contact, un lien de prise de rendez-vous. C'est pourtant par lui que vos clients vous trouvent, vous écrivent et vous font confiance. S'il peut être détourné, c'est votre nom qui sert d'appât.
La bonne nouvelle : l'essentiel de sa protection tient en quelques lignes de réglages, gratuites, que le serveur envoie au navigateur avec chaque page. On les appelle des en-têtes de sécurité. Le visiteur ne les voit jamais, mais son navigateur les applique à la lettre.
Les explications se lisent d'une traite ; les détails techniques sont rangés dans des encarts « Le détail technique », à déplier si vous êtes curieux. Ce guide complète celui consacré à la messagerie.
Votre site, une boutique sur la rue
Imaginez votre site comme une boutique. Le navigateur de votre visiteur est son guide : il le conduit jusqu'à la porte, lui montre les rayons, porte ses achats. Et ce guide est très obéissant : il suit les consignes que la boutique affiche à l'entrée.
Ces consignes, ce sont les en-têtes de sécurité. « N'entrez que par la porte blindée. » « N'acceptez que les livraisons de ces fournisseurs. » « Ne laissez personne exposer notre vitrine chez lui. » Sans elles, le navigateur applique des règles par défaut, très permissives, héritées des débuts du Web.
Ces consignes ne remplacent pas un site à jour : un logiciel vulnérable reste vulnérable. Mais elles empêchent qu'une petite faille devienne un piège pour vos clients, et elles comptent parmi ce que les assureurs cyber regardent avant de vous proposer un contrat.
Le détail techniquevoir les en-têtes d'un site soi-même
Les en-têtes accompagnent chaque page. On peut les lire depuis un simple terminal Windows :
PS C:\> (Invoke-WebRequest https://www.fhconsulting.fr -Method Head).Headers
Strict-Transport-Security max-age=31536000
Content-Security-Policy default-src 'none'; script-src 'self'; …
X-Frame-Options SAMEORIGIN
X-Content-Type-Options nosniff
Referrer-Policy same-origin
Permissions-Policy camera=(), microphone=(), geolocation=(), …Dans Chrome ou Edge, la touche F12, onglet Réseau, affiche les mêmes informations : cliquez sur la première ligne, puis sur « En-têtes ».
HTTPS : la porte blindée et la carte professionnelle
Une adresse en https:// signifie que tout ce qui passe entre le visiteur et votre site est chiffré : personne sur le trajet ne peut lire ce qu'il tape dans votre formulaire, ni modifier la page qu'il reçoit. C'est la porte blindée.
Pour l'ouvrir, le site présente un certificat, l'équivalent d'une carte professionnelle délivrée par une autorité reconnue. Le navigateur vérifie qu'elle est authentique, valide, et établie au bon nom ; sinon il affiche une alerte qui fait fuir n'importe quel visiteur.
Les certificats sont aujourd'hui gratuits (Let's Encrypt, que la plupart des hébergeurs installent automatiquement) mais ont une durée de vie courte, trois mois au plus : c'est leur renouvellement automatique qu'il faut surveiller. Pour aller plus loin, l'enregistrement CAA, présenté dans le guide messagerie, désigne les seules autorités qui ont le droit de délivrer vos certificats.
La redirection : un panneau vers l'entrée
Beaucoup de visiteurs tapent encore « fhconsulting.fr » sans préciser https://. Leur navigateur frappe alors à la porte de service, non chiffrée. Le site doit immédiatement les renvoyer vers l'entrée blindée : c'est la redirection vers HTTPS.
Un détail compte : cette première redirection doit rester sur le même nom. Si http://fhconsulting.fr renvoie directement vers https://www.fhconsulting.fr, le navigateur ne passe jamais par https://fhconsulting.fr et ne reçoit jamais la consigne HSTS du domaine principal, celle qui protège aussi tous ses sous-domaines. C'était le cas de mon propre site, jusqu'à ce que l'Observatory de Mozilla me le signale.
Le détail techniquel'ordre des redirections dans un fichier .htaccess (Apache, OVHcloud)
RewriteEngine On
# 1) http -> https, sur le même nom
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]
# 2) ensuite seulement : fhconsulting.fr -> www.fhconsulting.fr
RewriteCond %{HTTP_HOST} ^fhconsulting\.fr$ [NC]
RewriteRule ^(.*)$ https://www.fhconsulting.fr/$1 [L,R=301]Inverser ces deux blocs suffit à faire perdre la consigne HSTS du domaine principal. Le code 301 indique une redirection permanente, que les moteurs de recherche reportent sur la bonne adresse.
HSTS : la consigne mémorisée
La redirection a une faiblesse : la toute première demande, avant d'être redirigée, part en clair. Sur un Wi-Fi public, un espion peut l'intercepter et garder le visiteur sur une version piégée, non chiffrée, de votre site.
La consigne HSTS règle le problème. À la première visite chiffrée, le site dit au navigateur : « pendant un an, ne viens chez moi que par la porte blindée ». Le navigateur s'en souvient et, aux visites suivantes, passe directement en HTTPS, sans jamais frapper à la porte de service.
Reste la toute première visite. Pour elle, les navigateurs tiennent une liste de préchargement : les domaines qui y sont inscrits sont traités en HTTPS d'office, dès la première fois. L'inscription est gratuite, mais difficile à défaire : à réserver aux domaines dont tous les sous-domaines sont en HTTPS pour de bon.
Le détail techniqueles consignes HSTS de fhconsulting.fr, et comment les mettre en place sans risque
# sur https://fhconsulting.fr : tout le domaine et ses sous-domaines
Strict-Transport-Security: max-age=31536000; includeSubDomains
# sur https://www.fhconsulting.fr
Strict-Transport-Security: max-age=31536000max-age: la durée de la consigne, en secondes (31536000 = un an ; l'Observatory demande au moins six mois) ;includeSubDomains: la consigne vaut pour tous les sous-domaines, qui doivent donc tous répondre en HTTPS ;preload, ajouté plus tard si l'on veut s'inscrire sur la liste de préchargement (hstspreload.org).
Méthode prudente : commencer par une journée (max-age=86400), vérifier pendant une semaine que tout fonctionne, puis passer à un an. Un navigateur qui a reçu la consigne la garde jusqu'à son expiration, même si vous la retirez.
CSP : la liste des fournisseurs
Une page web assemble des éléments venus de plusieurs endroits : vos propres fichiers, des polices de caractères, un agenda en ligne, parfois un outil de statistiques. Si un pirate parvient à glisser son propre script dans une page (par une faille d'une extension, un formulaire mal protégé), ce script s'exécute chez chaque visiteur : il peut lire ce qu'il tape, le rediriger vers une fausse page de paiement.
La politique de sécurité du contenu (CSP, Content Security Policy) est la liste des fournisseurs autorisés, affichée à l'entrée. Le navigateur refuse tout ce qui n'y figure pas, y compris les scripts écrits directement dans la page, la porte d'entrée habituelle des injections.
C'est la protection la plus efficace contre l'injection de code, et la plus exigeante : il faut ranger tous les scripts et les styles du site dans des fichiers séparés. Sur fhconsulting.fr, cela a représenté plus de deux cents morceaux de script et de style à déplacer, pour un résultat invisible à l'œil, et dix points de plus à l'Observatory de Mozilla.
Le détail techniquela CSP de fhconsulting.fr, directive par directive
default-src 'none';
script-src 'self';
style-src 'self' https://fonts.googleapis.com;
font-src 'self' https://fonts.gstatic.com;
img-src 'self' data:;
connect-src 'self';
frame-src https://calendar.google.com;
form-action 'self'; frame-ancestors 'self';
base-uri 'self'; object-src 'none';
upgrade-insecure-requestsdefault-src 'none': tout est interdit par défaut ; chaque type de ressource est ensuite autorisé explicitement ;script-src 'self': seuls les scripts du site lui-même, aucun script écrit dans la page ;frame-src: seul l'agenda Google de prise de rendez-vous peut s'afficher dans une page ;form-action 'self': les formulaires ne peuvent être envoyés qu'au site lui-même.
Pour ne rien casser, publiez d'abord la politique en observation, sous le nom Content-Security-Policy-Report-Only : le navigateur signale dans sa console (F12) ce qu'il aurait bloqué, sans rien bloquer. Une fois la console silencieuse, on passe en mode actif.
Clickjacking : la vitrine non copiable
Un site malveillant peut afficher le vôtre à l'intérieur du sien, dans un cadre rendu invisible, et placer dessous un bouton anodin (« Fermer », « Gagner un cadeau »). Le visiteur croit cliquer sur ce bouton ; il clique en réalité sur votre site, par exemple pour valider un formulaire. C'est le détournement de clic, ou clickjacking.
La parade tient en une consigne : « personne d'autre que moi ne peut exposer ma vitrine ». Elle s'écrit frame-ancestors 'self' dans la CSP, ou, pour les navigateurs anciens, X-Frame-Options: SAMEORIGIN.
Si l'une de vos pages doit être intégrée ailleurs (un formulaire affiché sur le site d'un partenaire, par exemple), on fait une exception pour cette seule page, en nommant les sites autorisés.
Cookies : les bracelets d'accès
Quand un visiteur se connecte à un espace client ou à l'administration du site, il reçoit un cookie de session : un bracelet d'accès qui lui évite de redonner son mot de passe à chaque page. Celui qui vole le bracelet entre à sa place.
Trois attributs protègent ce bracelet : Secure (il ne circule que chiffré), HttpOnly (les scripts de la page ne peuvent pas le lire, même en cas d'injection) et SameSite (un autre site ne peut pas s'en servir à l'insu du visiteur). Les sites WordPress, Prestashop ou Wix les posent généralement bien ; les développements sur mesure plus anciens, pas toujours.
À ne pas confondre avec la question du consentement aux cookies (RGPD) : ici, il s'agit de la solidité des cookies techniques, pas de leur finalité.
SRI : les livraisons scellées
Beaucoup de sites chargent des scripts directement chez un fournisseur extérieur : une bibliothèque, un widget, un outil de statistiques. Si ce fournisseur est piraté, le code malveillant est livré à tous ses clients d'un coup.
Ce n'est pas théorique : en juin 2024, le service polyfill.io, racheté par un nouvel exploitant, a modifié sa bibliothèque pour rediriger les visiteurs mobiles vers des sites frauduleux. Plus de 100 000 sites qui la chargeaient ont été touchés, sans que leurs propriétaires aient rien changé.
L'intégrité des sous-ressources (SRI) est un scellé sur la livraison : la page indique l'empreinte exacte du script attendu, et le navigateur refuse un colis dont le scellé ne correspond plus. Le plus simple reste encore d'héberger ces scripts sur votre propre site, comme le fait fhconsulting.fr.
Le détail techniqueun script externe scellé
<script src="https://cdn.exemple.com/biblio-3.7.1.min.js"
integrity="sha384-…empreinte du fichier…"
crossorigin="anonymous"></script>L'empreinte change à chaque version : on scelle donc une version précise (3.7.1), jamais une adresse « dernière version ».
Les petits réglages qui comptent
- Étiquette du colis (
X-Content-Type-Options: nosniff) : le navigateur n'interprète pas un fichier autrement que son type déclaré ; une image piégée ne peut pas se faire passer pour un script. - Discrétion (
Referrer-Policy) : quand un visiteur clique sur un lien sortant, le site de destination ne reçoit pas l'adresse complète de la page qu'il quittait, qui peut contenir des informations personnelles. - Plaque sans marque : beaucoup de serveurs annoncent la version exacte de leurs logiciels (
Server: Apache/2.4.41,X-Powered-By: PHP/7.4). Un cambrioleur qui connaît la marque de la serrure sait quel outil apporter. Ces mentions se masquent en une ligne. - Permissions (
Permissions-Policy) : le site déclare n'avoir besoin ni de la caméra, ni du micro, ni de la localisation ; même un script injecté ne pourra pas les demander.
Isolation avancée : COOP, CORP, COEP
Trois consignes plus récentes isolent votre site des autres onglets et des autres sites : COOP coupe le lien entre vos pages et les fenêtres ouvertes par d'autres sites, CORP empêche d'autres sites de réutiliser vos fichiers, COEP n'accepte dans vos pages que des ressources explicitement partagées.
Elles protègent surtout les applications qui manipulent des données sensibles. Pour un site vitrine, elles sont facultatives et demandent de la prudence : COEP bloquerait un agenda intégré, CORP posé sur les images empêcherait de les afficher dans vos e-mails. L'Observatory les récompense par un bonus, sans pénaliser leur absence.
La note de l'Observatory de Mozilla
Mozilla, l'éditeur de Firefox, publie un outil gratuit qui contrôle ces consignes et attribue une note, de F à A+ : l'Observatory, intégré au site de référence des développeurs web (MDN). On part de 100 points ; chaque protection manquante en retire, chaque protection avancée en ajoute, mais seulement si la note atteint déjà 90.
Un site vitrine sans aucun en-tête de sécurité obtient souvent autour de 30 sur 100 (D), même s'il passe bien en HTTPS. Mon propre site affichait 105 avant la correction de sa redirection, et 120 depuis que plus aucun script ni style n'est écrit dans ses pages.
Mon test gratuit calcule cette note avec le moteur open source de l'Observatory, selon le même barème, en même temps qu'il analyse votre messagerie. Il vérifie aussi votre certificat et signale les versions logicielles affichées par votre serveur.
En résumé, et par où commencer
| Protection | En une image | Ce qu'elle protège |
|---|---|---|
| HTTPS et certificat | La porte blindée, la carte professionnelle | La confidentialité des échanges, l'identité du site |
| Redirection | Le panneau vers l'entrée | Les visiteurs qui tapent l'adresse sans https:// |
| HSTS | La consigne mémorisée | Les visites sur un Wi-Fi public |
| CSP | La liste des fournisseurs | Vos visiteurs, contre l'injection de code |
| frame-ancestors | La vitrine non copiable | Les clics de vos visiteurs |
| Cookies | Les bracelets d'accès | Les sessions de vos clients et de l'administration |
| SRI | Les livraisons scellées | Vos pages, contre un fournisseur piraté |
| Versions masquées | La plaque sans marque | Votre serveur, contre les attaques ciblées |
- Vérifier HTTPS et la redirection : toutes les adresses (avec et sans www, en http) doivent aboutir en https, en passant d'abord par le même nom.
- Ajouter les en-têtes simples :
X-Content-Type-Options,Referrer-Policy,X-Frame-Options, masquage des versions. Une ligne chacun, sans risque. - Activer HSTS pour une journée, puis pour un an une fois les essais concluants.
- Publier une CSP en observation, corriger ce que la console signale, puis l'activer.
- Héberger ou sceller les scripts externes, et vérifier les attributs des cookies si le site a un espace connecté.
- Refaire le test après chaque changement, et surveiller l'échéance du certificat.
Questions fréquentes
Mon hébergeur ne s'en occupe-t-il pas déjà ?
En partie seulement. La plupart installent le certificat HTTPS et proposent la redirection, mais les en-têtes de sécurité dépendent de votre site : l'hébergeur ne peut pas deviner quels fournisseurs vos pages utilisent. Chez OVHcloud, ils se règlent dans le fichier .htaccess du site.
Ces réglages peuvent-ils casser mon site ?
Les en-têtes simples, non. La CSP et HSTS, oui, s'ils sont publiés sans préparation : une CSP trop stricte bloque un widget, une consigne HSTS trop longue empêche d'accéder à un sous-domaine resté en http. D'où la méthode : CSP en observation d'abord, HSTS d'une journée d'abord, et un test après chaque étape.
Mon site est sous WordPress, comment faire ?
Les en-têtes peuvent être ajoutés dans le fichier .htaccess, par l'hébergeur ou avec une extension dédiée à la sécurité. La CSP y est plus délicate, car beaucoup d'extensions écrivent des scripts directement dans les pages : on commence souvent par une politique en observation, qui permet déjà de repérer les extensions à revoir.
Le cadenas dans la barre d'adresse suffit-il ?
Non. Le cadenas garantit que la connexion est chiffrée et que le certificat est valide, pas que la page est saine. Un site parfaitement chiffré peut servir un script injecté, se laisser encadrer par un site piège ou exposer des cookies fragiles : c'est ce que couvrent les autres consignes.
Ces réglages améliorent-ils le référencement ?
HTTPS est un critère officiel de classement de Google depuis 2014, et un site signalé comme dangereux perd ses visiteurs. Les autres en-têtes ne sont pas des critères directs, mais ils protègent la réputation du site et la confiance de ceux qui le consultent.
Comment connaître la note de mon site ?
Mon test gratuit analyse à la fois votre messagerie et votre site, avec le même barème que l'Observatory de Mozilla, et peut vous envoyer le rapport en PDF. Pour corriger les points relevés avec votre prestataire, prenez rendez-vous : le premier échange de 20 minutes est offert.
Quelle note pour votre site ?
Testez-le gratuitement avec votre messagerie, ou faites le point avec moi : le premier rendez-vous de 20 minutes est offert.
Sources et références : MDN, méthode de notation de l'HTTP Observatory · OWASP Secure Headers Project · Sansec, attaque de la chaîne d'approvisionnement polyfill.io (2024) · Google, HTTPS comme critère de classement (2014) · en-têtes publics de fhconsulting.fr relevés en octobre 2026.