Protéger un serveur web des attaques : mesures vérifiables

Mis à jour le 1er novembre 2026. Article réécrit et enrichi. Nous avons ajouté les risques de l’OWASP Top 10:2025, la veille CERT-FR (dont l’alerte PHP du 21 octobre 2026), des commandes d’inventaire, la récupération de l’adresse réelle derrière un proxy, le mode test de la limitation de débit, le blocage du PHP dans les dossiers de médias et un tableau de vérification complété.

Les attaques contre les sites web sont largement automatisées. Des outils, dont certains s’appuient sur l’IA, sondent les serveurs en continu, reprennent un essai qui échoue et répartissent leurs requêtes sur plusieurs adresses. Le délai entre la publication d’une faille et les tentatives d’exploitation se réduit.

Les points d’entrée restent pourtant les mêmes : logiciels non mis à jour, configurations faibles, comptes mal protégés, droits trop larges, sauvegardes non testées. Ce guide s’adresse aux personnes qui administrent un serveur WordPress, PrestaShop ou une API. Il décrit des mesures vérifiables, sans technique d’attaque.

Partir des risques : l’OWASP Top 10:2025

L’OWASP Top 10 classe les risques les plus fréquents des applications web. L’édition 2025 fait monter la mauvaise configuration à la deuxième place et ajoute deux catégories : les défaillances de la chaîne d’approvisionnement logicielle et la mauvaise gestion des conditions exceptionnelles. Cinq catégories concernent directement l’administration d’un serveur.

Catégorie OWASP 2025	Ce qu’elle recouvre côté serveur	Mesure de cet article
A02 Security Misconfiguration	Services inutiles, fichiers exposés, réglages par défaut	Réduire la surface exposée
A03 Software Supply Chain Failures	Extensions, modules et dépendances vulnérables ou compromis	Mises à jour, inventaire, veille
A07 Authentication Failures	Mots de passe seuls, essais répétés	Second facteur, clés SSH, limitation de débit
A09 Security Logging and Alerting Failures	Journaux absents ou alertes jamais lues	Journaliser et alerter
A10 Mishandling of Exceptional Conditions	Messages d’erreur trop bavards, comportement qui reste ouvert en cas d’échec	Mode debug désactivé en production

A01 (contrôle d’accès, qui intègre désormais les SSRF) et A05 (injections) relèvent surtout du code de l’application.

Mettre à jour et suivre les avis de sécurité

Mettez à jour le système, le serveur web, PHP, le cœur du CMS, ses extensions et ses modules. Supprimez ce que vous n’utilisez plus : un composant désactivé reste présent sur le disque. Testez en préproduction lorsque c’est possible. La démarche pour un VPS est détaillée dans notre guide de mise à jour sécurisée.

Commencez par un inventaire :

# Versions des composants exposés
nginx -v
php -v

# Paquets système en attente (Debian, Ubuntu)
apt list --upgradable

# WordPress : cœur et extensions à mettre à jour (WP-CLI)
wp core version
wp plugin list --update=available

Abonnez-vous au flux RSS du CERT-FR, qui publie des alertes, des avis de sécurité et des recommandations de durcissement. Le 21 octobre 2026, il a ainsi émis l’alerte CERTFR-2026-ALE-014 sur plusieurs vulnérabilités de PHP, détaillée dans notre article Faille critique PHP : alerte php2shell.

Réduire la surface exposée

Ports et services

La CNIL recommande de n’ouvrir que les ports nécessaires, par exemple 443 pour un accès HTTPS seul. Listez les services à l’écoute :

sudo ss -tlnp

Une base de données ou un outil comme phpMyAdmin ne doit pas être joignable depuis Internet. N’exposez pas non plus les dossiers de sauvegarde.

Fichiers sensibles, PHP dans les médias et signature du serveur

# Note : à tester avant mise en production, puis nginx -t && systemctl reload nginx
server_tokens off;                      # masque la version de Nginx

location ~ /\.(?!well-known) {          # .env, .git, .htaccess...
    deny all;
}

location ~* ^/wp-content/uploads/.*\.php$ {
    deny all;                           # aucun PHP exécutable dans les médias
}

Nginx retient la première location à expression régulière qui correspond : placez ces blocs avant votre bloc location ~ \.php$. Adaptez le chemin des médias à votre application. Si aucun service n’utilise xmlrpc.php, ce que vos journaux permettent de vérifier, refusez-en l’accès :

location = /xmlrpc.php {
    deny all;
}

Masquer la version ne corrige aucune faille : cela retire seulement une information.

Le robots.txt n’est pas une protection

La norme RFC 9309 le dit explicitement : les règles du robots.txt ne sont pas une forme d’autorisation d’accès. Lister /admin/ ou /backup/ dans ce fichier indique leur emplacement à tout le monde. Certains robots d’IA ne le suivent d’ailleurs pas toujours : OpenAI précise que les règles peuvent ne pas s’appliquer à ChatGPT-User, déclenché par un utilisateur. Pour contrôler la charge, utilisez la limitation de débit.

Limiter le débit sur les points d’entrée sensibles

La connexion, les formulaires et les API doivent refuser un volume anormal de requêtes d’une même source. Le module limit_req de Nginx applique un algorithme de « seau qui fuit ». Par défaut, il répond 503 aux requêtes refusées ; un code 429 est plus explicite.

# Note : valeurs d'exemple, à adapter et à tester avant la mise en production
# Bloc http { } :
limit_req_zone $binary_remote_addr zone=connexion:10m rate=5r/m;

# Bloc location = /wp-login.php existant :
limit_req zone=connexion burst=5 nodelay;
limit_req_status 429;
limit_req_dry_run on;   # phase de test : compte sans bloquer

Avec limit_req_dry_run on, les dépassements sont comptés sans être bloqués. Ajoutez $limit_req_status à votre format de journal : la variable vaut PASSED, REJECTED_DRY_RUN ou REJECTED. Observez quelques jours, puis retirez le mode test. Selon la documentation, une zone de 1 Mo garde environ 8 000 états sur une plateforme 64 bits.

Derrière un CDN ou un reverse proxy

Sans configuration, toutes les requêtes semblent venir du proxy, et la limitation bloque tout le monde à la fois. Le module realip remplace l’adresse par celle transmise par le proxy, à condition de déclarer uniquement les adresses de confiance :

set_real_ip_from 192.0.2.0/24;   # plages de votre proxy ou CDN
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Ce module n’est pas compilé par défaut : vérifiez avec nginx -V 2>&1 | grep -o with-http_realip_module. Un réseau d’entreprise peut aussi regrouper des visiteurs légitimes derrière une même adresse.

Protéger l’accès à l’administration

Activez un second facteur ou les passkeys pour tous les administrateurs, comme l’explique le guide de migration vers WebAuthn. Si possible, limitez les back-offices à des adresses fixes ou à un VPN : voir VPN ou ZTNA pour le back-office PrestaShop. Changer l’URL d’administration réduit le bruit dans les journaux, sans protéger à lui seul.

Pour SSH, utilisez des clés et désactivez l’authentification par mot de passe :

# Note : gardez une session SSH ouverte et testez une connexion par clé avant de recharger
# Fichier /etc/ssh/sshd_config
PasswordAuthentication no

Vérifiez la syntaxe avec sudo sshd -t avant de recharger le service. Côté site, la CNIL recommande les attributs HttpOnly et Secure sur tous les cookies et TLS sur l’ensemble du site. Pour préparer la suite, voir chiffrement post-quantique et Nginx.

Appliquer le moindre privilège

un utilisateur système dédié par site ;
un utilisateur de base de données limité à sa propre base ;
des fichiers de code que le serveur web ne peut pas modifier, lorsque l’application le permet ;
des comptes administrateur nominatifs, revus régulièrement ;
le mode debug désactivé en production : un message d’erreur détaillé renseigne un attaquant. Pour PrestaShop, voir activer et désactiver le mode debug.

Sauvegarder et tester la restauration

Une sauvegarde jamais restaurée n’est pas une garantie. Conservez fichiers et base hors du serveur, avec plusieurs points dans le temps : une copie faite après une compromission peut contenir le code malveillant. Restaurez régulièrement sur un environnement séparé et notez le délai obtenu.

Journaliser et alerter

Centralisez les journaux et conservez-les assez longtemps pour suivre une activité étalée sur plusieurs jours. Définissez des alertes sur les situations qui exigent une action : volume anormal sur la connexion, connexion administrateur inhabituelle, fichier PHP apparu dans les médias, modification du cœur de l’application, pic d’erreurs 5xx. Les commandes figurent dans l’article sur les logs de sécurité WordPress et dans l’analyse des logs Nginx.

Complétez par un contrôle d’intégrité : wp core verify-checksums compare le cœur de WordPress aux empreintes publiées. Notre scanner de malwares WordPress fait la même comparaison sans installer d’extension sur le site.

Ce que l’IA apporte à la défense

Elle est utile sur des tâches précises :

Trier les alertes : regrouper les événements similaires et mettre en avant ce qui mérite d’abord votre attention.
Repérer les écarts : apprendre une référence (heures de connexion, volumes par page) et signaler ce qui s’en écarte.
Corréler plusieurs sources : un SIEM rapproche les journaux du serveur, de l’application et du pare-feu.
Résumer : un récapitulatif quotidien facilite la relecture.

Pour l’intégrité d’un fichier, une comparaison d’empreintes est déterministe et suffit. La réponse automatique convient aux actions réversibles et de faible impact, comme ralentir une source. Évitez de bloquer automatiquement de larges plages d’adresses : vous pourriez couper des visiteurs ou Googlebot. Toute action sensible doit être validée par une personne.

Ce qu’elle ne garantit pas

L’absence de faux positifs et de faux négatifs. Tenez un historique des alertes pour mesurer la fiabilité.
Une protection contre les failles à elle seule. Sans mise à jour, la détection ne ferme pas la faille.
Une explication de chaque décision. Relisez les données brutes.
Une référence saine. Si la période d’apprentissage contient déjà une activité anormale, la référence est faussée.
La conformité. Les journaux contiennent des adresses IP, qui peuvent être des données personnelles. Vérifiez où elles sont traitées avant tout envoi à un service externe.

Vérifier que vos défenses fonctionnent

Mesure	Ce qu’elle limite	Comment la vérifier
Mises à jour	Exploitation de failles publiées	Comparer les versions installées aux avis CERT-FR et éditeurs
Surface réduite	Accès à des services et fichiers inutiles	`ss -tlnp` ; `curl -I https://votre-site.example/.env` doit renvoyer 403 ou 404
PHP bloqué dans les médias	Exécution d’un fichier déposé	Un fichier PHP de test dans le dossier doit renvoyer 403
Limitation de débit	Essais répétés	Réponses 429 et `$limit_req_status` dans les journaux
Adresse réelle	Blocage collectif derrière un proxy	Les journaux montrent les IP des visiteurs, pas celle du proxy
Authentification forte	Accès avec un simple mot de passe	Tous les administrateurs ont un second facteur ; SSH refuse les mots de passe
Sauvegardes testées	Perte de données	Restauration sur un environnement séparé, délai noté
Alertes	Délai de détection	Déclencher une alerte de test et vérifier sa réception

Questions fréquentes

Par quoi commencer sur un serveur existant ?

Faites l’inventaire des versions, des extensions, des comptes administrateurs, des ports ouverts et de la dernière restauration réussie. Corrigez ensuite dans cet ordre : mises à jour, accès, surface exposée, sauvegardes, puis alertes.

Un pare-feu applicatif suffit-il pour WordPress ou PrestaShop ?

Non. Un WAF filtre une partie du trafic, mais aucune règle n’est infaillible, et une règle mal réglée bloque des visiteurs légitimes. Il ne remplace ni les mises à jour, ni les droits limités, ni l’authentification forte. Voir aussi IA locale ou WAF cloud pour PrestaShop.

La limitation de débit peut-elle gêner Googlebot ?

Oui, si elle s’applique à tout le site avec un seuil bas. Google réduit son exploration quand il reçoit beaucoup de 429 ou de 5xx. Limitez les pages de connexion, les formulaires et les API, pas les pages publiques.

Comment savoir si une alerte générée par une IA est fiable ?

Recoupez-la avec les journaux bruts et cherchez un événement banal qui l’explique : mise à jour, campagne, outil de supervision. Notez le résultat : cet historique donne le taux de faux positifs.

Sources

OWASP, Top 10:2025 et introduction de l’édition 2025
CERT-FR, alertes et avis de sécurité (alerte CERTFR-2026-ALE-014 du 21 octobre 2026)
CNIL, Sécuriser les sites web (fiche du 14 mars 2024)
Nginx, module ngx_http_limit_req_module
Nginx, module ngx_http_realip_module
IETF, RFC 9309 : Robots Exclusion Protocol (septembre 2022)
OpenAI, Robots d’exploration d’OpenAI
Google Search Central, Réduire la vitesse d’exploration de Googlebot

L'équipe Genisoft Agence web PrestaShop & WordPress

Agence web spécialisée PrestaShop et WordPress : création, maintenance, sécurité, performance et référencement. Nos tutoriels sont issus de nos interventions sur de vraies boutiques.

L'agence Genisoft → LinkedIn →