Pourquoi des en-têtes de sécurité ?
Avec quelques lignes dans la configuration du serveur web, tu indiques au navigateur avec quelle rigueur traiter ton site : le charger uniquement en HTTPS, ne pas exécuter de scripts étrangers, ne pas l’afficher dans des cadres étrangers. Cela ne coûte rien et écarte des classes entières d’attaques.
Les six en-têtes les plus importants
- Strict-Transport-Security (HSTS) : le navigateur ne charge plus le site qu’en HTTPS, même si quelqu’un tape http:// ou clique sur un ancien lien.
- Content-Security-Policy (CSP) : définit d’où peuvent venir scripts, styles et images. La protection la plus efficace contre le cross-site scripting, mais aussi la plus exigeante. Teste-la d’abord en
Content-Security-Policy-Report-Only. - X-Frame-Options / frame-ancestors : empêche d’autres sites d’intégrer le tien de façon invisible et de piéger les clics (clickjacking).
- X-Content-Type-Options: nosniff : le navigateur respecte le type de fichier indiqué au lieu de le deviner.
- Referrer-Policy : quelle part de l’adresse actuelle est transmise aux autres sites.
- Permissions-Policy : quelles fonctions du navigateur comme la caméra, le micro ou la position peuvent être utilisées.
Comment la note est-elle calculée ?
Chacun des six en-têtes rapporte un point s’il est défini et pas manifestement inefficace. Six points donnent A, cinq B, etc. A+ exige en plus aucun avertissement ouvert et une CSP qui restreint vraiment les scripts. Sans HTTPS ou avec un certificat invalide, la note est F. La note est indicative : un site sans connexion ni formulaire a moins de besoins qu’un portail client.
Conseils de mise en œuvre
Définis les en-têtes là où la réponse est produite. Si un reverse proxy ou un CDN est placé devant, ils doivent souvent y être définis. Avec nginx, add_header dans un bloc location remplace tous les en-têtes du bloc server, et sans always ils manquent sur les pages d’erreur. Avec HSTS et includeSubDomains, tous les sous-domaines doivent supporter HTTPS.
Vérifie le certificat lui-même avec la vérification SSL et les AC autorisées avec le générateur CAA.
FAQ
Pourquoi l’outil affiche-t-il d’autres en-têtes que mon navigateur ?
Certains serveurs répondent différemment selon le navigateur, la langue ou la connexion. La vérification est une requête anonyme sans cookies. Les en-têtes définis seulement après connexion n’apparaissent pas ici.
Ai-je vraiment besoin d’une Content Security Policy ?
Pour un site statique sans formulaire, le risque est faible. Dès que des utilisateurs se connectent ou saisissent des données, une CSP est la meilleure protection contre le JavaScript injecté. Commence en Report-Only et active-la quand plus aucune violation n’est signalée.
X-XSS-Protection n’est-il pas important ?
Non, plus maintenant. Tous les navigateurs actuels ont supprimé le filtre XSS, et dans les anciennes versions il pouvait même créer des failles. Supprime-le ou mets-le à 0.
La vérification charge-t-elle mon site ?
Non. Une seule requête est envoyée (plus une par redirection et une pour http://), et le contenu est coupé après les en-têtes.
Puis-je vérifier des sites internes ?
Non, le serveur de hollop.net n’interroge que des adresses publiques. Pour les sites internes, utilise la commande curl -sI du résultat dans ton propre réseau.