« Les en-têtes de réponse HTTP liés à la sécurité doivent être présents sur toutes les pages, pas seulement sur la page de connexion. » Ce principe, rappelé dans la plupart des guides de durcissement serveur sérieux, prend un relief particulier pour un site du secteur assurantiel, où la moindre faille de configuration expose des données de souscription et de sinistres particulièrement sensibles.
Cette checklist se rejoue systématiquement avant chaque mise en ligne d’un site de ce secteur, indépendamment de ce qui a déjà été vérifié sur le plan applicatif : elle porte uniquement sur la couche serveur, celle que WordPress ne contrôle jamais directement.
1. Vérifier les ports réellement exposés
Un scan externe du serveur, réalisé depuis une machine hors du réseau interne de l’hébergeur, révèle parfois des ports ouverts par défaut sans lien avec le site web : un service de base de données accessible depuis l’extérieur, un panneau d’administration système exposé sans restriction d’accès.
nmap -Pn -p- exemple-assurance.fr
2. Restreindre l’accès administrateur par IP
Le répertoire wp-admin d’un site sensible ne doit jamais rester accessible depuis n’importe quelle adresse, quand l’équipe qui l’administre travaille depuis un nombre limité d’adresses connues :
location /wp-admin/ {
allow 203.0.113.0/24;
deny all;
}
3. Vérifier les en-têtes de sécurité HTTP
Chaque en-tête se vérifie individuellement, pas de façon globale, car un test automatisé peut signaler « en-têtes présents » alors qu’un seul chemin du site les applique réellement :
curl -I https://exemple-assurance.fr/devis/simuler/
Strict-Transport-Securityavec une durée suffisamment longue et l’optionincludeSubDomains;X-Content-Type-Options: nosniff;Content-Security-Policy, même restrictive au départ, plutôt qu’absente ;Referrer-Policy: strict-origin-when-cross-origin.
4. Vérifier les permissions du système de fichiers
Les permissions par défaut d’une installation WordPress laissent parfois wp-config.php accessible en lecture à d’autres comptes du même serveur mutualisé, un risque réel sur un hébergement partagé qui héberge plusieurs clients :
chmod 640 wp-config.php
chown www-data:www-data wp-config.php
5. Contrôler la version TLS acceptée
Un serveur qui accepte encore TLS 1.0 ou 1.1 par compatibilité historique doit être corrigé avant l’ouverture d’un site sensible, ces versions étant considérées obsolètes par l’ensemble des référentiels de sécurité récents :
ssl_protocols TLSv1.2 TLSv1.3;
6. Vérifier les sauvegardes automatiques et leur chiffrement
Une sauvegarde qui existe mais qui n’est jamais testée en restauration n’est qu’une hypothèse. La checklist impose une restauration test complète, sur un environnement isolé, avant l’ouverture au public.
7. Journaliser sans exposer
Les journaux d’accès et d’erreurs doivent être conservés pour l’investigation d’incident, mais jamais accessibles publiquement via une URL directe, un oubli fréquent sur les configurations Nginx par défaut :
location ~ /\.log$ {
deny all;
}
8. Documenter chaque point vérifié
Chaque point de cette checklist se documente avec la date de vérification et la personne qui l’a réalisée, dans un registre conservé indépendamment du serveur lui-même, pour pouvoir prouver la démarche de durcissement en cas de contrôle.
Un principe qui structure cette checklist depuis plusieurs mises en ligne sensibles : aucun point ne se considère acquis parce qu’il l’était sur le projet précédent, chaque serveur se vérifie depuis zéro.
En résumé
Durcir la configuration serveur d’un site d’assurance avant sa mise en ligne repose sur une checklist reproductible, point par point, qui couvre la couche que WordPress ne maîtrise jamais directement : ports exposés, en-têtes HTTP, permissions du système de fichiers et version TLS acceptée. Chaque point vérifié réduit une surface d’attaque bien réelle sur un secteur particulièrement ciblé.
