Introduction

ModSecurity est un pare‑feu applicatif (WAF) qui protège votre site en filtrant les requêtes HTTP suspectes. Il peut toutefois bloquer des requêtes légitimes (faux positifs). Ce guide explique comment identifier la cause d’un blocage, retrouver la règle (Rule ID) et appliquer une correction ciblée (désactivation d’une règle, exception par domaine, whitelist IP) sans désactiver ModSecurity globalement.

En bref : récupérez l’URL bloquée, l’heure exacte, l’IP cliente et la capture d’écran du message ; consultez cPanel → Metrics → Errors et, si vous avez WHM, utilisez ModSecurity Tools → Hits List pour trouver le Rule ID. Préférez toujours une exception ciblée au remplacement ou à la désactivation globale du WAF.

Prérequis

  • Accès cPanel (hébergement mutualisé) ou WHM/SSH (VPS / dédié, accès administrateur).
  • URL exacte et heure (format ISO/W3C) de la requête bloquée ; capture d’écran du message d’erreur (ex. 403).
  • Adresse IP cliente (votre IP si vous testez), méthode HTTP (GET/POST) et User‑Agent si possible.

Avant de commencer — principe de sécurité

Ne coupez jamais ModSecurity globalement en production. L’objectif est d’identifier la règle exacte et d’appliquer un contournement ciblé : désactiver une règle spécifique, créer une exception pour un domaine ou autoriser une IP. Si vous n’êtes pas administrateur, fournissez toutes les preuves au support technique.

Procédure pas‑à‑pas

Si vous avez seulement un compte cPanel (hébergement mutualisé)

  1. Reproduire et collecter les informations.

    Ouvrez la page bloquée, copiez l’URL complète, notez l’heure exacte (ex. 2026‑10‑17T15:32:08Z), le code HTTP affiché (souvent 403) et faites une capture d’écran du message.

  2. Vérifier l’outil ModSecurity dans cPanel.

    Si votre hébergeur a exposé l’outil, cherchez Security → ModSecurity dans cPanel. Vous pouvez y activer/désactiver temporairement pour tester, mais réactivez immédiatement après le test.

  3. Consulter les erreurs Apache (cPanel).

    Dans cPanel, ouvrez Metrics (ou Performance) → Errors pour voir les dernières lignes du journal d’erreurs liées à votre domaine ; cela permet parfois d’identifier la règle ou le motif du blocage.

  4. Si la cause n’apparaît pas.

    Ouvrez un ticket auprès de l’hébergeur en joignant : URL, heure (ISO), IP cliente, capture d’écran et la description. Demandez explicitement la vérification des hits ModSecurity / du modsec_audit.log pour la requête concernée.

Si vous êtes administrateur WHM (VPS / dédié)

  1. Ouvrir ModSecurity Tools → Hits List.

    WHM → Security Center → ModSecurity Tools → Hits List. La Hits List affiche les événements récents ; cliquez sur une entrée pour voir le Rule ID, le message, l’URI, l’IP cliente et le score éventuel.

  2. Identifier la règle (Rule ID) et l’action.

    Notez le Rule ID et le type d’action (log, pass, block). Ces informations déterminent la correction : désactiver la règle, créer une exception ou signaler un faux positif au fournisseur du jeu de règles.

  3. Appliquer une correction ciblée.

    Évitez SecRuleEngine Off. Préférez :

    • désactiver la règle précise (par Rule ID) ;
    • ou créer une exception limitée au domaine ou à l’IP concernée.

    Attention aux règles « vendor » : leur gestion peut être automatisée par le fournisseur et nécessite de documenter toute modification.

Logs : où chercher (emplacements courants)

Les chemins varient selon la configuration du serveur. Emplacements habituels :

  • /usr/local/apache/logs/modsec_audit.log
  • /var/log/apache2/modsec_audit.log ou répertoires par utilisateur /etc/apache2/logs/modsec_audit/USERNAME

Recherchez la même heure ou le même unique_id que l’erreur et notez le Rule ID et la partie Action (log/pass/block).

Commandes utiles (avancé — accès root / SSH)

# suivre les dernières lignes du log d'audit
sudo tail -f /usr/local/apache/logs/modsec_audit.log

# rechercher une IP précise ou une URL
sudo grep -n '203.0.113.45' /usr/local/apache/logs/modsec_audit.log | less
sudo grep -n '/chemin/qui/pose/probleme' /usr/local/apache/logs/modsec_audit.log | less

Mode diagnostic : audit & « détection seulement »

Pour diagnostiquer sans bloquer, basculez temporairement le moteur en mode « détection only » (WHM → Security Center → ModSecurity Configuration) ou augmentez le niveau d’audit. Attention : le niveau « log all transactions » enregistre tout le trafic (données privées) et peut remplir rapidement le disque. Utilisez‑le uniquement pour un débogage ponctuel et surveillez l’espace disque.

Procédure d’escalade — que fournir au support

Joignez toujours :

  • URL complète et heure (format ISO, timezone) ;
  • capture d’écran du message d’erreur ;
  • méthode HTTP (GET/POST) et champs du formulaire si POST ;
  • IP cliente et User‑Agent ;
  • extrait du log Apache/ModSecurity autour de la même heure (si accessible) ;
  • contexte (mise à jour, plugin installé, modification récente).

Exemple de message (copier/coller) :

Objet : Blocage ModSecurity — demande d’analyse

Bonjour,

Mon site example.com subit des 403 lors d’un POST vers /chemin-exemple le 2026-10-17T15:32:08Z depuis l’IP 203.0.113.45.
Pouvez‑vous :
 - vérifier les hits ModSecurity / modsec_audit.log autour de cette date/heure ;
 - indiquer le Rule ID et le message associé ;
 - proposer une action (exception par domaine, règle à désactiver pour l’user, ou autre).

PJ : capture d’écran et URL.

Merci.

Cas fréquents & solutions rapides

  • Hits List vide : vérifiez que l’audit log est activé (Audit Log Level). Si non, demandez au support d’activer la journalisation.
  • Audit log trop volumineux : réduisez temporairement le niveau d’audit après diagnostic et configurez une rotation des logs.
  • Plugin WordPress bloqué : identifiez la règle et créez une exception ciblée plutôt que de couper ModSecurity pour l’ensemble du domaine.
  • Requêtes POST bloquées : vérifiez la taille et le contenu du corps de la requête ; identifiez la règle et créez une exception ciblée.

Limitations et bonnes pratiques

  • Ne supprimez pas une règle fournisseur (vendor) sans comprendre l’impact ; préférez une exception locale.
  • Conservez les logs pendant le diagnostic et activez la rotation (logrotate) pour éviter l’épuisement d’espace disque.
  • Ne partagez jamais de mots de passe ni de jetons dans un ticket ; masquez les données sensibles des extraits de log.

Ressources officielles

Articles internes utiles

Besoin d’aide pour interpréter un extrait de log ou préparer le ticket ? Copiez ici l’extrait (masquez les données sensibles) et nous vous aidons à l’analyser.

Documentation de référence

  • ModSecurity® Tools | cPanel & WHM Documentation
  • ModSecurity® Configuration | cPanel & WHM Documentation
  • The cPanel & WHM Log Files | cPanel & WHM Documentation

Documentation consultée le 17 octobre 2026. Les outils peuvent varier selon votre hébergement.