mirror of
https://github.com/owasp-modsecurity/ModSecurity.git
synced 2026-01-09 01:34:36 +03:00
Adding section on precedence over other apache modules. Explaining the case of mod_headers as an example.
@@ -4097,6 +4097,18 @@ Examples Apache mod_log_config:
|
||||
LogFormat "%t %{UNIQUE_ID}e %{MULTIPART_STRICT_ERROR}M %{TX.ANOMALY_SCORE}M" custom-format
|
||||
</pre>
|
||||
|
||||
== Precedence of ModSecurity over other Apache modules ==
|
||||
|
||||
ModSecurity rules run in one of five phases. The first two phases are executed as the request is being read, the third and the fourth phase are executed after the response has been generated and the fifth phase when the response has been sent and the logfile has been written.
|
||||
|
||||
The various phases are hooked into the Apache request lifecycle together with the other Apache modules. On each hook, there can be more than one module being executed. This is where precedence comes into play.
|
||||
|
||||
Precedence is assigned at compile time and mostly hard-coded into the ModSecurity source code. The directive _--enable-request-early_ can used to move the processing of the ModSecurity phase 1 to a different hook.
|
||||
|
||||
When examining the response, ModSecurity tries to be as early as possible. For example, the phase 3 and phase 4 will run before mod_headers with its _Header_ directive. However, when calling _Header_ with the keyword _early_, the precedence is raised and the directive is executed before ModSecurity phase 3.
|
||||
So if you want to edit HTTP response headers with mod_headers (adding the secure-flag to cookies springs to mind), you will usually have to wait until ModSecurity phase 5, before you can examine the effect of the header manipulation with ModSecurity.
|
||||
|
||||
Also see Processing Phases (above).
|
||||
|
||||
= A Recommended Base Configuration =
|
||||
|
||||
|
||||
Reference in New Issue
Block a user