Les différentes phases :

Phase 1 : Entête de la requête HTTP
Apache vient de lire les entêtes de la requête (cookies, authorization tokens, ...).
Les arguments ne sont pas encore connus.
Cette phase intervient avant qu'Apache ne puisse faire quelque chose.
Les traitement des directives d'emplacements (VirtualHost, Directory, Location, ...) doivent être effectuées en pahse 2.

Phase 2 : Corps de la requête HTTP
On a les arguments de la requêtes, on peut faire le traitement des règles applicatives.
Liste des encodages supportés :
- application/x-www-form-urlencoded (données de formulaires)
- multipart/form-data (transfert de fichiers)
- text/xml (parsing de fichier XML)

Phase 3 : Entête de la réponse HTTP
Cette phase intervient juste avant que les entêtes de réponses ne parviennent au client.
Les règles de filtrage permettent de définir ce qu’il doit advenir de la réponse (analyse ou non du contenu/corps de la réponse ou la bloquer).
On ne sait pas encore ce qu'Apache va répondre au client.

Phase 4 : Corps de la réponse HTTP
A cette phase, les règles se focalisent sur le contenu qui sera renvoyé au client, permettant d'intercepter des erreurs, des fuites d'informations ainsi que des échecs d'authentification.

Phase 5 : Journalisation
A ce niveau on intervient seulement sur la manière dont la journalisation sera effectuée.
Il est trop tard pour interdire, bloquer ou modifier le contenu qui sera renvoyé au client.

SecAuditLogParts

A Entête du log d’audit (obligatoire)
B Entête de la requête
C Corps de la requête (présent si elle existe et que ModSecurity est configuré pour l'intercepter)
D Réservé et non implémenté
E Corps de la réponse intermédiaire (présent si ModSecurity est configuré pour l'intercepter et que le moteur de log d'audit est configuré pour l'enregistrer)
F Entête de réponse finale
G Réservé et non implémenté
H Fin du log d’audit
I Remplace en partie C excepté qu'il ne log pas quand l'encodage multipart/form-data est utilisé.
J Cette partie contient les informations des fichiers encodés en multipart/form-data
K Cette partie contient la liste de chaque règle que à marchée (nue par ligne), supportée depuis la v2.5.0
Z Marqueur de fin de requête (obligatoire)

Les directives principales :

Directives Description
SecServerSignature Personnalisation du type de serveur renvoyé au client
SecRuleEngine Indique le type mode : On|Off|DetectionOnly (seulement des alertes)
SecRequestBodyAccess Indique si ModSecurity analyse le corp des requêtes
SecResponseBodyAccess Indique si ModSecurity analyse le corp des réponses
SecDataDir Répertoire permettant à ModSecurity de stocker ses informations persistantes (IP, session, ...)
SecDebugLogLevel Niveau de verbosité des logs
SecAuditEngine Indique le type de journalisation : On/Off/RelevantOnly (seulement les alertes)
SecAuditLogRelevantStatus Indique quels status code HTTP doivent être enregistré, ex : ^[45] pour les erreurs 4xx et 5xx
SecAuditLogParts Indique les parties de la requête à enregistrer (ABCDEFGHIJKZ)
SecRequestBodyLimit Taille max du corps de la requête accepté, si elle excède ModSecurity enverra un 413.
SecRule Déclaration d'une règle de filtrage
SecDebugLog Path du fichier debug de ModSecurity
SecAuditLog Path du fichier d'audit de ModSecurity
SecTmpDir Path des fichiers temporaires de ModSecurity

ID de règle :

Les IDs de règles faisant partie de 1-99999 sont des règles customs/personnels.