En-têtes de sécurité et score

1. Ce que teste la section Security Headers

La section Security Headers se connecte à votre site en HTTPS (ou en HTTP si HTTPS échoue), suit les redirections puis analyse les en-têtes de la réponse finale. Dans la plupart des cas, il s’agit du HTML de votre page d’accueil.

Pour chaque en-tête important, DNSprobe vérifie s’il est présent, si sa valeur semble sûre et s’il respecte les recommandations actuelles (par exemple HSTS, CSP, X-Content-Type-Options, Referrer-Policy, drapeaux de cookies, etc.).

L’objectif n’est pas d’obtenir un score théorique académique, mais une vue concrète de la façon dont votre site protège les visiteurs contre des risques courants comme le contenu mixte, le clickjacking, le MIME sniffing ou le vol de session.

2. Comprendre le score et la note

Le score affiché par DNSprobe va de 0 à 100 et est converti en une note de A à F. Les points sont répartis entre plusieurs en-têtes : certains comptent davantage (CSP, HSTS) tandis que d’autres sont purement informatifs.

Une note A ne signifie pas que votre application est invulnérable ; elle indique simplement que vos en-têtes HTTP sont globalement alignés avec ce qui est recommandé aujourd’hui pour un site typique.

À l’inverse, un score bas ne veut pas forcément dire que le site est catastrophique. Certaines applications assouplissent volontairement certaines politiques (par exemple pour autoriser les iframes ou des accès cross-origin plus larges). Utilisez le score comme un indicateur, toujours replacé dans le contexte de votre projet.

• A ou B : en-têtes globalement bien configurés. Vous pouvez encore affiner CSP, permissions et reporting, mais les bases sont en place.
• C ou D : plusieurs en-têtes importants manquent ou sont trop permissifs. Il vaut la peine de revoir les recommandations et de renforcer progressivement la configuration.
• F : le serveur n’envoie quasiment aucun en-tête de sécurité. C’est fréquent sur des sites anciens ou des configurations par défaut, mais il est fortement recommandé d’améliorer cela avant la mise en production.

3. En-têtes clés et rôle concret

Voici un résumé des en-têtes les plus impactants analysés par DNSprobe et de ce qu’ils apportent de concret pour vos visiteurs.

Certains en-têtes peuvent être gérés en amont par un proxy inverse, un CDN ou un serveur applicatif. Ce qui compte, c’est la combinaison finale reçue par le navigateur.

4. Utiliser le modèle .htaccess généré par DNSprobe

Sous le tableau, DNSprobe génère un modèle .htaccess « optimal » basé sur les modules Apache comme mod_headers et mod_rewrite. Il propose des valeurs réalistes pour HSTS, CSP, la protection des iframes, les cookies, CORS et plus encore.

Ce modèle sert de point de départ. Vous devez toujours le relire, adapter les directives à votre application et à votre pile (Apache, LiteSpeed, etc.) et déployer les changements progressivement, idéalement sur un environnement de préproduction.

Certaines lignes sont volontairement commentées car plus agressives (CSP stricte, réécriture automatique des cookies, reporting, etc.). Ne les activez que lorsque vous comprenez l’impact et avez vérifié que votre application continue de fonctionner correctement.

• Si vous utilisez déjà un gestionnaire de cache (LiteSpeed Cache, WP Rocket, proxy inverse, etc.), laissez l’exemple de Cache-Control HTML commenté et laissez le plugin gérer la mise en cache.
• Ajustez les listes CORS et les endpoints de reporting avec vos propres domaines avant de les activer en production.
• Après avoir déployé le modèle, relancez un rapport DNSprobe et vérifiez à la fois le score des en-têtes de sécurité et le reste du rapport (HTTPS, HSTS, contenu mixte, etc.).

Le modèle de .htaccess généré par DNSprobe est un point de départ que vous devez adapter à votre propre pile (Apache, LiteSpeed, équivalents Nginx, règles CDN, proxies inverses, etc.) avant de le déployer en production.

5. Conseils pratiques et erreurs fréquentes

Le durcissement des en-têtes HTTP se fait par étapes. Quelques réflexes permettent de garder une configuration propre dans le temps :

• Commencez par les en-têtes non bloquants (HSTS sur un site 100 % HTTPS, X-Content-Type-Options, Referrer-Policy) avant d’introduire des règles CSP ou Permissions-Policy plus strictes.
• Testez avec les outils de développement du navigateur ouverts et surveillez les ressources bloquées ou les violations CSP dans la console.
• Si vous utilisez un CDN ou un WAF, vérifiez s’il injecte ses propres en-têtes. Des directives dupliquées ou contradictoires peuvent produire des comportements surprenants.
• Appliquez les changements d’abord en préproduction ou sur un petit pourcentage de trafic, puis déployez progressivement en production une fois rassuré.
• Documentez la raison d’être de chaque en-tête afin que les administrateurs suivants sachent ce qu’ils peuvent modifier ou non.

6. Limites de l’analyse automatique des en-têtes

DNSprobe n’analyse qu’une seule URL : en général la page d’accueil du site. D’autres chemins (admin, API, téléchargements, sous-domaines historiques) peuvent utiliser des en-têtes différents et doivent être testés séparément s’ils exposent des données sensibles.

Certaines applications envoient des en-têtes dynamiques selon l’utilisateur, le pays ou l’appareil. Dans ce cas, DNSprobe reflète uniquement le comportement d’une requête anonyme depuis son propre point de présence.

Enfin, aucun scanner automatique ne peut décider à votre place quelles exceptions sont légitimes. Utilisez le rapport comme une liste de contrôle détaillée, puis appliquez votre propre analyse de risque pour décider ce qu’il faut renforcer ou assouplir.

7. Tester les en-têtes HTTP de sécurité manuellement depuis votre propre terminal

La section Security Headers de DNSprobe analyse les en-têtes de réponse HTTP renvoyés par votre site (HSTS, Content-Security-Policy, X-Frame-Options, Referrer-Policy, Permissions-Policy, etc.) et vous attribue un score. Vous pouvez examiner les mêmes en-têtes depuis un terminal en utilisant curl sur la version HTTPS de votre site.

Linux : utiliser curl pour inspecter les en-têtes de réponse

Sur la plupart des distributions Linux, curl est installé ou disponible dans les dépôts par défaut. Les commandes suivantes ne récupèrent que les en-têtes de réponse HTTP en HTTPS, afin que vous puissiez revoir tous les en-têtes de sécurité renvoyés par votre serveur :

                curl -I https://example.com/
    
                # Vue rapide de la ligne de statut et des principaux en-têtes (HSTS, CSP, X-Frame-Options, Referrer-Policy, etc.)    
                curl -s -D - -o /dev/null https://example.com/
        

macOS : utiliser curl avec les outils intégrés

macOS inclut curl dans ses outils en ligne de commande. Ouvrez Terminal et exécutez les mêmes commandes que sous Linux pour voir exactement quels en-têtes de sécurité votre site envoie en HTTPS :

                curl -I https://example.com/
    
                # Vue rapide de la ligne de statut et des principaux en-têtes (HSTS, CSP, X-Frame-Options, Referrer-Policy, etc.)    
                curl -s -D - -o /dev/null https://example.com/
        

Windows : utiliser curl depuis l’Invite de commandes ou PowerShell

Sur les versions récentes de Windows 10 et 11, curl est inclus par défaut. Depuis une fenêtre Invite de commandes ou PowerShell, vous pouvez utiliser curl comme sous Linux/macOS pour inspecter vos en-têtes de sécurité :

                curl -I https://example.com/
    
                REM Vue rapide de la ligne de statut et des principaux en-têtes (HSTS, CSP, X-Frame-Options, Referrer-Policy, etc.)    
                curl -s -D - -o nul https://example.com/
        

Important : ne testez que des hôtes et domaines que vous possédez ou que vous êtes autorisé à analyser. Des vérifications répétées et automatisées des en-têtes sur des systèmes tiers sans autorisation peuvent être considérées comme un comportement abusif par certains fournisseurs.