Conversation
Signed-off-by: Felipe Zipitria <felipe.zipitria@owasp.org>
Deploying crs-documentation with
|
| Latest commit: |
9f10c39
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://ca8ecd58.documentation-km5.pages.dev |
| Branch Preview URL: | https://chore-add-early-blocking-doc.documentation-km5.pages.dev |
Co-authored-by: Xhoenix <86168235+Xhoenix@users.noreply.github.com>
| > **Enable early execution of phase 1 rules** | ||
| > By default, ModSecurity does **not** activate this flag. Phase 1 rules run **after** the request headers are fully read. This flag allows certain phase 1 rules to trigger *earlier*, potentially before the full header set is available. |
There was a problem hiding this comment.
I think this is the wrong way around. @airween? Didn't the issue say they used --disable-request-early?
There was a problem hiding this comment.
Yes, @theseion is right. I think we should suggest don't use --disable-request-early flag.
There was a problem hiding this comment.
Ugh. Is it just the name, or the behavior completely changes? Can you point me to the docs?
There was a problem hiding this comment.
I just found this one:
Starting with ModSecurity 2.7.0 there are a few important configuration options
- --enable-request-early - On ModSecurity 2.6 phase one has been moved to phase 2 hook, if you want to play around it use this option.
But in configure.ac, the logic is in opposite direction:
if test "$enableval" != "no"; then
request_early="-DREQUEST_EARLY"
MODSEC_EXTRA_CFLAGS="$MODSEC_EXTRA_CFLAGS $request_early"
else
request_early=
fi
],
[
request_early='-DREQUEST_EARLY'
The logic:
- if the user passes this option, and the value is not
no(which equals with--disable-request-early, then feature will be turned ON - if the user does not pass this option, then the build script assumes it's necessary and will be turned ON
There was a problem hiding this comment.
Ping @coreruleset/core-developers
There was a problem hiding this comment.
Pull request overview
This PR documents the --enable-request-early ModSecurity compilation flag in the CRS known issues section, addressing issue #221. The documentation explains why this flag should remain disabled by default and describes the risks associated with enabling it. Additionally, the PR reorganizes the existing known issues with improved formatting using emojis for better visual structure.
Changes:
- Added comprehensive documentation for ModSecurity's
--enable-request-earlyflag including motivation, technical details, risks, and recommendations - Reorganized existing known issues into categorized sections (Apache, ModSecurity, Debian, CRS + ModSecurity, libmodsecurity3)
- Enhanced visual structure with emoji icons for improved readability
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| ```plaintext | ||
| Error parsing actions: Unknown action: \\ | ||
| Action 'configtest' failed.` |
There was a problem hiding this comment.
The formatting inside the code block is inconsistent. Line 72 ends with a backtick that doesn't match the opening backticks on line 70. The backtick at the end of line 72 should be removed - it appears to be a stray character that would cause the code block to render incorrectly.
| Action 'configtest' failed.` | |
| Action 'configtest' failed. |
| ### 🛠️ Enabling the flag | ||
|
|
||
| ```bash | ||
| ./configure --enable-request-early | ||
| make | ||
| make install | ||
| ``` |
There was a problem hiding this comment.
The example configuration commands suggest compiling ModSecurity with the --enable-request-early flag. However, this documentation is for the CRS (Core Rule Set), not ModSecurity itself. Users reading CRS documentation would typically install pre-compiled ModSecurity packages. Consider clarifying that this flag must be set when compiling ModSecurity from source, and that users need to check with their package maintainer or compile ModSecurity themselves to enable this flag. The current wording could confuse users who are only installing/configuring CRS.
|
|
||
| Support for the URLENCODED body processor was only added in ModSecurity 3.0.3. To resolve this, upgrade to ModSecurity 3.0.3 or higher. | ||
| Support for the URLENCODED body processor was only added in ModSecurity 3.0.3. | ||
| :warning: Please do not use such an older version of ModSecurity. Upgrade to the latest and greatest. |
There was a problem hiding this comment.
Inconsistent punctuation within the bullet points. Line 84 ends with a period after the code block, while line 89 does not. For consistency across the documentation, either all bullet point sentences should end with periods or none should. Review the entire section to ensure consistent punctuation style.
| :warning: Please do not use such an older version of ModSecurity. Upgrade to the latest and greatest. | |
| :warning: Please do not use such an older version of ModSecurity. Upgrade to the latest and greatest.. |
4 participants
what
Fixes #221