Test de sécurité du serveur web: la checklist complète

Un test de sécurité d'un serveur web vérifie neuf éléments: la configuration du protocole TLS et des chiffres, la validité du certificat, les en-têtes de sécurité HTTP, la Content Security Policy, les attributs des cookies, la divulgation des versions logicielles, les vulnérabilités connues du serveur et du CMS, la configuration DNSSEC et les services et méthodes exposés inutilement. La plupart de ces éléments peuvent être vérifiés gratuitement en moins d'une minute depuis un navigateur, et tous sont des problèmes de configuration, ce qui signifie qu'ils peuvent être corrigés sans toucher au code applicatif.

Les vulnérabilités des applications retiennent l’attention, mais une grande partie de l’exposition réelle provient d’une simple configuration de serveur: une version TLS obsolète toujours activée, un en-tête Server indiquant la version exacte, un cookie de session sans l’attribut Secure, aucune Content Security Policy. Aucun de ces éléments ne requiert un bug dans votre code. Tous sont visibles de l’extérieur, ce qui signifie qu’un attaquant les repère avant vous.

L'avantage est que les problèmes de configuration sont peu coûteux à corriger. Cette liste de contrôle détaille ce qu'il faut tester, pourquoi chaque élément compte et comment le vérifier sans rien installer.

Check-list de sécurité du serveur web

1. Protocoles TLS et suites de chiffrement

SSL 3.0, TLS 1.0 et TLS 1.1 sont obsolètes et doivent être désactivés purement et simplement. TLS 1.2 avec des suites de chiffrement modernes constitue le minimum requis, TLS 1.3 étant l'objectif. Les suites de chiffrement doivent fournir le secret partagé, afin qu'une compromission future de la clé privée ne permette pas de déchiffrer rétroactivement le trafic capturé.

Les éléments spécifiques à supprimer: RC4, 3DES, chiffres d'exportation, tout élément avec échange de clés NULL ou anonyme, et les suites en mode CBC pour lesquelles une alternative moderne existe.

À ajouter à la liste en 2026: la préparation post-quantique. Le trafic chiffré capturé aujourd’hui peut être stocké et déchiffré ultérieurement une fois les ordinateurs quantiques capables, ce qui en fait une préoccupation actuelle pour tout actif à horizon de confidentialité long.

Testez tout cela avec le SSL Security Test gratuit, qui couvre les serveurs web et de messagerie et signale la préparation à la cryptographie post-quantique ainsi que la conformité à PCI DSS, GDPR, HIPAA et NIST.

2. Validité et chaîne du certificat

Trois modes de défaillance expliquent la quasi-totalité des incidents liés aux certificats. Le certificat expire, généralement sur un hôte dont personne ne se souvenait qu’il était dans le périmètre. La chaîne intermédiaire est incomplète, ce qui entraîne un fonctionnement dans un navigateur de bureau qui met en cache les intermédiaires, mais une défaillance sur les appareils mobiles et dans les clients API. Ou bien le certificat ne couvre pas le nom d’hôte réellement utilisé, généralement un «www» ou un nouveau sous-domaine.

Ces trois éléments sont invisibles jusqu'à ce qu'ils échouent. La surveillance continue est la seule véritable solution, car un certificat valide aujourd'hui expire à une échéance que personne ne suit.

3. HTTP Strict Transport Security

HSTS ordonne aux navigateurs de refuser l'HTTP en clair pour votre domaine. Sans lui, la toute première requête d'un utilisateur peut être interceptée et rétrogradée avant même que votre redirection vers HTTPS n'ait lieu.

Un en-tête de production approprié:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

N’ajoutez includeSubDomains que lorsque vous êtes certain que chaque sous-domaine sert HTTPS, et considérez preload comme une porte à sens unique, car la suppression de la liste de preload est lente.

4. Content Security Policy

and

L'efficacité d'une politique repose sur son caractère strict. La directive `script-src 'self' 'unsafe-inline'` n'offre pratiquement aucune protection, car `unsafe-inline` autorise précisément l'injection que l'en-tête est censé empêcher. Utilisez plutôt des nonces ou des hachages. Un joker de source tel que `script-src *` pose le même problème sous une forme différente.

Commencez en mode report-only, collectez les violations depuis le trafic réel, resserrez, puis appliquez. Le Website Security Test gratuit évalue la force de la politique CSP plutôt que sa simple présence, ce qui est l’élément qui compte réellement.

5. Les autres en-têtes de sécurité

X-Content-Type-Options: nosniff empêche les navigateurs de deviner le type de contenu, ce qui transforme un fichier soumis par l'utilisateur en script exécutable.

X-Frame-Options: DENY, ou mieux, frame-ancestors 'none' dans le CSP, prévient le clickjacking en bloquant l'encadrement de vos pages.

Referrer-Policy: «strict-origin-when-cross-origin» empêche les URL complètes, y compris tout identifiant présent dans le chemin d’accès ou la chaîne de requête, d’être divulguées à des tiers via l’en-tête Referer.

Permissions-Policy désactive les fonctionnalités du navigateur que le site n’utilise pas, telles que la caméra, le microphone et la géolocalisation, limitant ainsi les capacités des scripts injectés.

6. Attributs des cookies

Chaque cookie de session exige trois attributs. Secure empêche la transmission via HTTP en clair. HttpOnly rend le cookie inaccessible à JavaScript, ce qui transforme de nombreuses détections XSS en simples désagréments plutôt qu'en détournements de compte. SameSite=Lax ou Strict bloque le motif «cross-site request forgery».

Il s'agit d'un changement d'une seule ligne dans la quasi-totalité des frameworks, mais il manque encore sur une grande part des sites en production.

7. Divulgation des versions logicielles

Les en-têtes «Server: Apache/2.4.29 (Ubuntu)» et «X-Powered-By: PHP/7.2.24» indiquent précisément à un attaquant quels exploits publiés tenter, avant même qu’il n’ait envoyé la moindre requête intéressante. Les balises méta Generator, les chemins d’accès aux ressources versionnés et les pages d’erreur par défaut divulguent les mêmes informations.

La suppression des en-têtes n'est pas une solution en soi, car l'obscurité ne répare rien, mais elle vous retire des listes cibles des balayages automatisés de masse, ce qui constitue une réduction significative du bruit.

8. Vulnérabilités connues du serveur et du CMS

La divulgation des versions n'a d'importance que parce que les logiciels obsolètes sont si fréquents. Un serveur web, un CMS et ses plugins ont chacun leur propre cadence de mise à jour, et les plugins constituent généralement le maillon faible, car ils sont installés une fois pour toutes et ne sont plus jamais réexaminés.

Le Test de sécurité web gratuit identifie les composants logiciels obsolètes et vulnérables en plus des vérifications d'en-têtes et de CSP ; aucun outil distinct n'est donc nécessaire.

9. DNSSEC et services exposés

DNSSEC signe les réponses DNS afin qu'elles ne puissent pas être falsifiées en cours de transmission. Sans lui, un attaquant capable de manipuler le DNS peut rediriger vos utilisateurs vers son serveur avec un certificat valide qu'il a obtenu lui-même.

En plus du DNS, vérifiez les expositions inutiles du serveur: TRACE et autres méthodes HTTP inutiles, listes de répertoires, répertoires .git, fichiers de sauvegarde, panneaux d’administration accessibles depuis l’internet public, ainsi que les endpoints d’état ou de métriques laissés ouverts.

Vérifications connexes à effectuer

Un serveur web ne fonctionne pas seul. Trois tests complémentaires comblent les failles restantes et prennent une minute chacun.

L'Email Security Test vérifie le volet messagerie, où les problèmes de configuration TLS et d'authentification sont bien plus fréquents than sur le serveur web, tout simplement parce que personne n'y prête attention.

Website Privacy Test indique quels scripts, traceurs et pixels tiers vos pages chargent et où vos formulaires sont envoyés, ce qui est directement pertinent si le serveur gère des paiements.

Dark Web and Threat Exposure Test analyse l'extérieur pour détecter les identifiants fuités, les domaines squat et les sites de hameçonnage utilisant votre marque, lesquels ne figurent pas dans une analyse de serveur.

Comment lancer le test

Le chemin le plus rapide est le Website Security Test gratuit pour les en-têtes, le CSP, le DNSSEC, les versions logicielles et la conformité au RGPD et à la norme PCI DSS, ainsi que le SSL Security Test gratuit pour la couche de chiffrement. Les deux se lancent depuis le navigateur, ne nécessitent aucun compte et retournent une note avec un rapport téléchargeable.

Pour les vérifications répétées, les deux tests s’exécutent depuis la ligne de commande via iwtools, disponible sous forme de script Python et d’image Docker:

./iwtools.py websec --api-key ABCDE-12345-FGHIJ-67890 --recheck -p
https://example.com
./iwtools.py ssl --api-key ABCDE-12345-FGHIJ-67890 --recheck -p example.com:443

Un code de sortie 0 signifie que tous les contrôles configurés ont réussi, tandis qu'un code 3 indique qu'au moins un a échoué. Cela suffit pour faire échouer un déploiement lorsqu'un en-tête disparaît ou qu'un chiffrement faible réapparaît.

Au-delà d’un test ponctuel

Dérive de configuration. Les certificats expirent, une mise à jour de plugin supprime un en-tête, un nouveau sous-domaine est lancé sans application de ces mesures. Un test vous indique où vous en êtes un jour donné.

ImmuniWeb® Discovery identifie en continu les actifs exposés à Internet, y compris ceux non déclarés par la sécurité, et surveille leur configuration, leurs certificats et leur posture de conformité au fil du temps. ImmuniWeb® Neuron couvre la couche applicative au-dessus du serveur avec un SLA garantissant zéro faux positif.