coreruleset · fzipi · Feb 25, 2026 · Feb 19, 2026 · Feb 19, 2026 · Feb 19, 2026
diff --git a/static/images/logo.png → assets/logo.png b/static/images/logo.png → assets/logo.png
diff --git a/config/_default/config.toml b/config/_default/config.toml
@@ -16,8 +16,12 @@ home = ['html', 'rss', 'print']
   author.name = "CRS project"
   # Shows a checkmark for visited pages on the menu
   showVisitedLinks = true
+  # Logo image displayed in the sidebar
+  logo = { direction = 'column' }
+  # Text below the logo in the sidebar
+  linkTitle = ''
   # Disable search function. It will hide search bar
-  search.disable=false
+  search.disable = false
   # Javascript and CSS cache are automatically busted when new version of site is generated.
   # Set this to true to disable this behavior (some proxies don't handle well this optimization)
   disableAssetsBusting = false

diff --git a/content/1-getting-started/1-1-crs-installation.md b/content/1-getting-started/1-1-crs-installation.md
@@ -18,7 +18,7 @@ For *production* environments, it is recommended to use the latest release, whic
 
 ### Verifying Releases
 
-{{% notice note %}}
+{{% notice style="note" icon="key" %}}
 Releases are signed using the CRS project's [GPG key](https://coreruleset.org/security.asc) (fingerprint: 3600 6F0E 0BA1 6783 2158 8211 38EE ACA1 AB8A 6E72). Releases can be verified using GPG/PGP compatible tooling.
 
 To retrieve the CRS project's public key from public key servers using `gpg`, execute: `gpg --keyserver pgp.mit.edu --recv 0x38EEACA1AB8A6E72` (this ID should be equal to the last sixteen hex characters in the fingerprint).
@@ -95,7 +95,7 @@ Other aspects of ModSecurity, particularly engine-specific parameters, are contr
 
 In many scenarios, the default example CRS configuration will be a good enough starting point. It is, however, a good idea to take the time to look through the example configuration file *before* deploying it to make sure it's right for a given environment.
 
-{{% notice warning %}}
+{{% notice style="warning" icon="shield-halved" %}}
 In particular, _Response_ rules are enabled by default. You must be aware that you may be vulnerable to RFDoS attacks, depending on the responses your application is sending back to the client. You could be vulnerable, if your responses from your application can contain user input. If an attacker can submit user input that is returned as part of a response, the attacker can craft the input in such a way that the response rules of the WAF will block responses containing that input _for all_ clients. For example, a blog post might no longer be accessible because of the contents of a comment on the post. See [this blog post](https://blog.sicuranext.com/response-filter-denial-of-service-a-new-way-to-shutdown-a-website/) about the problems you could face.
 There is an [experimental scanner](https://github.com/edoardottt/RFDos-Scanner) that uses [nuclei](https://github.com/projectdiscovery/nuclei?tab=readme-ov-file#install-nuclei) to find out if are affected. So if
 you are unsure, first test your application before enabling the response rules, or risk accidentally blocking some valid responses.

diff --git a/content/1-getting-started/1-2-extended_install.md b/content/1-getting-started/1-2-extended_install.md
@@ -39,7 +39,7 @@ ModSecurity is frequently pre-packaged and is available from several major Linux
 
 For Windows, get the latest MSI package from https://github.com/owasp-modsecurity/ModSecurity/releases.
 
-{{% notice warning %}}
+{{% notice style="warning" icon="box-open" %}}
 **Distributions might not update their ModSecurity releases frequently.** 
 
 As a result, it is quite likely that a distribution's version of ModSecurity may be missing important features or **may even contain security vulnerabilities**. Additionally, depending on the package and package manager used, the ModSecurity configuration will be laid out slightly differently.
@@ -117,7 +117,7 @@ For *production* environments, it is recommended to use the latest release, whic
 
 ### Verifying Releases
 
-{{% notice note %}}
+{{% notice style="note" icon="key" %}}
 Releases are signed using the CRS project's [GPG key](https://coreruleset.org/security.asc) (fingerprint: 3600 6F0E 0BA1 6783 2158 8211 38EE ACA1 AB8A 6E72). Releases can be verified using GPG/PGP compatible tooling.
 
 To retrieve the CRS project's public key from public key servers using `gpg`, execute: `gpg --keyserver pgp.mit.edu --recv 0x38EEACA1AB8A6E72` (this ID should be equal to the last sixteen hex characters in the fingerprint).
@@ -233,6 +233,6 @@ Nginx will include files from the Nginx configuration directory (`/etc/nginx` or
   Include {{< param crs_install_dir >}}/plugins/*-after.conf
 ```
 
-{{% notice note %}}
+{{% notice style="note" icon="puzzle-piece" %}}
 You will also need to include the plugins you want along with your CRS installation.
 {{% /notice %}}
diff --git a/content/1-getting-started/1-4-engine_integration_options.md b/content/1-getting-started/1-4-engine_integration_options.md
@@ -88,15 +88,15 @@ Most big cloud providers and CDNs provide a CRS offering. While originally these
 
 The CRS project has some insight into some of these platforms and is in touch with most of these providers. The *exact specifics* are not really known, however, but what *is* known is that almost all of these integrators compromised and provide a *subset* of CRS rules and a *subset* of features, in the interests of ease of integration and operation.
 
-{{% notice info %}}
+{{% notice style="info" icon="cloud" %}}
 The [CRS Status page project](https://github.com/coreruleset/coreruleset/wiki/DevRetreat21StatusPage) will be testing cloud and CDN offerings. As part of this effort, the CRS project will be documenting the results and even publishing code on how to quickly get started using CRS in CDN/cloud providers. This status page project is in development as of spring 2022.
 {{% /notice %}}
 
 A selection of these platforms are listed below, along with links to get more info.
 
 ### AWS WAF
 
-{{% notice note %}}
+{{% notice style="note" icon="cloud" %}}
 AWS provides a rule set called the ["Core rule set (CRS) managed rule group"](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-baseline.html) which "…provides protection against… commonly occurring vulnerabilities described in OWASP publications such as OWASP Top 10."
 
 The CRS project does **not** believe that the AWS WAF "core rule set" is based on or related to OWASP CRS.

diff --git a/content/2-how-crs-works/2-1-anomaly_scoring/index.md b/content/2-how-crs-works/2-1-anomaly_scoring/index.md
@@ -89,7 +89,7 @@ Most detected inbound threats carry an anomaly score of 5 (by default), while sm
 
 Rule coverage should be taken into account when setting anomaly score thresholds. Different CRS rule categories feature different numbers of rules. SQL injection, for example, is covered by more than 50 rules. As a result, a real world SQLi attack can easily gain an anomaly score of 15, 20, or even more. On the other hand, a rare protocol attack might only be covered by a single, specific rule. If such an attack only causes the one specific rule to match then it will only gain an anomaly score of 5. If the inbound anomaly score threshold is set to anything higher than 5 then attacks like the one described will not be stopped. **As such, a CRS installation should aim for an inbound anomaly score threshold of 5.**
 
-{{% notice warning %}}
+{{% notice style="warning" %}}
 Increasing the anomaly score threshold above the defaults (5 for requests, 4 for responses), will allow a substantial number of attacks to bypass CRS and will impede the ability of critical rules to function correctly, such as LFI, RFI, RCE, and data-exfiltration rules. The anomaly score threshold should only ever be increased temporarily during false-positive tuning.
 
 Some WAF vendors (such as Cloudflare) set the default anomaly score well above our defaults. This is not a proper implementation of CRS, and will result in bypasses.
@@ -198,15 +198,15 @@ Early blocking makes this possible by inserting **two additional rounds of block
 More information about processing phases can be found in the [processing phases section](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)#processing-phases) of the ModSecurity Reference Manual.
 {{% /notice %}}
 
-{{% notice warning %}}
+{{% notice style="warning" icon="eye-slash" %}}
 The early blocking option has a major drawback to be aware of: **it can cause potential alerts to be hidden**.
 
 If a transaction is blocked early then its body is not inspected. For example, if a transaction is blocked early at the end of phase 1 (the request headers phase) then the body of the request is never inspected. If the early blocking option is *not* enabled, it's possible that such a transaction would proceed to cause phase 2 rules to match. Early blocking hides these potential alerts. The same applies to responses that trigger an early block: it's possible that some phase 4 rules would match if early blocking were not enabled.
 
 Using the early blocking option results in having less information to work with, due to fewer rules being executed. This may mean that the full picture is not present in log files when looking back at attacks and malicious traffic. It can also be a problem when dealing with false positives: tuning away a false positive in phase 1 will allow the same request to proceed to the next phase the next time it's issued (instead of being blocked at the end of phase 1). The problem is that now, with the request making it past phase 1, more, previously "hidden" false positives may appear in phase 2.
 {{% /notice %}}
 
-{{% notice warning %}}
+{{% notice style="warning" icon="bolt" %}}
 If early blocking is not enabled, there's a chance that the web server will interfere with the handling of a request between phases 1 and 2. Take the example where the Apache web server issues a redirect to a new location. With a request that violates CRS rules in phase 1, this may mean that the request has a higher anomaly score than the defined threshold but it gets redirected away before blocking evaluation happens.
 {{% /notice %}}
 

diff --git a/content/2-how-crs-works/2-2-paranoia_levels.md b/content/2-how-crs-works/2-2-paranoia_levels.md
@@ -20,7 +20,7 @@ A higher paranoia level makes it harder for an attacker to go undetected. Yet th
 
 When false positives occur they need to be tuned away. In ModSecurity parlance: rule exclusions need to be written. A rule exclusion is a rule that disables another rule, either disabled completely or disabled partially only for certain parameters or for certain URIs. This means **the rule set remains intact** yet the CRS installation is no longer affected by the false positives.
 
-{{% notice note %}}
+{{% notice style="note" icon="sliders" %}}
 Depending on the complexity of the service (web application) in question and on the paranoia level, the process of writing rule exclusions can be a *substantial* amount of work.
 
 This page won't explore the problem of handling false positives further: for more information on this topic, see the appropriate chapter or refer to the [tutorials at netnea.com](https://www.netnea.com/cms/apache-tutorials/).

diff --git a/content/2-how-crs-works/2-3-false-positives-and-tuning.md b/content/2-how-crs-works/2-3-false-positives-and-tuning.md
@@ -44,7 +44,7 @@ This example log entry provides lots of information about the rule match. Some o
 
   `[data "Matched Data: <h1> found within ARGS:wp_post: <h1>welcome to my blog</h1>"]`
 
-{{% notice tip %}}
+{{% notice style="tip" icon="puzzle-piece" %}}
 CRS ships with a prebuilt *rule exclusion package* for WordPress, as well as other popular web applications, to help prevent false positives. See the section on [rule exclusion packages]({{% ref "#rule-exclusion-packages" %}}) for details. 
 {{% /notice %}}
 
@@ -68,7 +68,7 @@ When working in strict blocking mode, false positives can cause legitimate user
 
 ### Directly Modifying CRS Rules
 
-{{% notice warning %}}
+{{% notice style="warning" icon="ban" %}}
 Making direct modifications to CRS rule files is a bad idea and is strongly discouraged.
 {{% /notice %}}
 
@@ -118,11 +118,11 @@ The different rule exclusion types and methods are summarized in the table below
 
 *\*\*Can also exclude ranges of rules (not currently supported in ModSecurity v3).*
 
-{{% notice tip %}}
+{{% notice style="tip" icon="file-arrow-down" %}}
 This table is available as a well presented, downloadable [Rule Exclusion Cheatsheet](https://www.netnea.com/cms/rule-exclusion-cheatsheet-download) from Christian Folini.
 {{% /notice %}}
 
-{{% notice note %}}
+{{% notice style="note" icon="link" %}}
 When using `SecRuleUpdateTargetById` and `ctl:ruleRemoveTargetById` with *chained rules*, target exclusions are only applied to the first rule in the chain. You can't exclude targets from other rules in the chain, depending on how the rule is written, you may have to remove the entire rule using `SecRuleRemoveById` or `ctl:ruleRemoveById`. This is a current limitation of the SecLang configuration language.
 {{% /notice %}}
 
@@ -206,7 +206,7 @@ The 'ctl' action for writing runtime rule exclusions does **not** support any us
 
   Runtime rule exclusions *modify* rules in some way. If a rule is to be modified then this should occur before the rule is executed (modifying a rule *after* it has been executed has no effect). As such, this type of rule exclusion must appear *before* the CRS and all its rules have been included.
 
-{{% notice tip %}}
+{{% notice style="tip" icon="folder-open" %}}
 CRS ships with the files `REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example` and `RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example`. After dropping the ".example" suffix, these files can be used to house "BEFORE-CRS" (i.e. runtime) and "AFTER-CRS" (i.e. configure-time) rule exclusions in their correct places relative to the CRS rules. These files also contain example rule exclusions to copy and learn from.
 {{% /notice %}}
 
@@ -338,7 +338,7 @@ SecRule REQUEST_URI "@beginsWith /webapp/login.html" \
     ctl:ruleRemoveTargetByTag=attack-sqli;REQUEST_COOKIES:uid"
 ```
 
-{{% notice tip %}}
+{{% notice style="tip" icon="code-branch" %}}
 It's possible to write a conditional rule exclusion that tests something other than just the request URI. Conditions can be built which test, for example, the source IP address, HTTP request method, HTTP headers, and even the day of the week.
 
 Multiple conditions can also be chained together to create a logical AND by using ModSecurity's [chain](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)#chain) action. This allows for creating powerful rule logic like "for transactions that are from source IP address 10.0.0.1 AND that are for location '/login.html', exclude the query string parameter 'user_id' from rule 920280". Extremely granular and specific rule exclusions can be written, in this way.
@@ -354,7 +354,7 @@ If using a native CRS installation, rule exclusion packages can be enabled in th
 
 If running CRS where it has been integrated into a commercial product or CDN then support varies. Some vendors expose rule exclusion packages in the GUI while other vendors require custom rules to be written which set the necessary variables. Unfortunately, there are also vendors that don't allow rule exclusion packages to be used at all.
 
-{{% notice tip %}}
+{{% notice style="tip" icon="location-dot" %}}
 If running multiple web applications, it is highly recommended to enable a rule exclusion package only for the location where the corresponding web application resides. For example, to enable the WordPress rule exclusion package only for locations under '/wordpress', a rule like the following could be used:
 
 ```apache

diff --git a/content/2-how-crs-works/2-4-sampling_mode.md b/content/2-how-crs-works/2-4-sampling_mode.md
@@ -49,7 +49,7 @@ In the latter case, where sampling mode is triggered and CRS is bypassed, an ale
 
 Here, CRS reports that it disabled the rule engine because the random number was above the sampling limit. The sampling percentage is set at the desired level, the rule set generates a random integer in the range 0-99 per-transaction, and if it’s *above* the sampling percentage then the WAF is disabled for the remainder of the transaction.
 
-{{% notice warning %}}
+{{% notice style="warning" icon="percent" %}}
 As sampling mode works by selectively disabling the ModSecurity WAF engine, if *other rule sets* are installed then they will be bypassed too.
 {{% /notice %}}
 

diff --git a/content/3-about-rules/creating.md b/content/3-about-rules/creating.md
@@ -5,7 +5,7 @@ disableToc: false
 chapter: false
 ---
 
-{{% notice note %}}
+{{% notice style="note" icon="clock-rotate-left" %}}
 **The content on this page may be outdated.** We are currently in the process of rewriting all of our documentation: please bear with us while we update our older content.
 {{% /notice %}}
 

diff --git a/content/3-about-rules/metadata.md b/content/3-about-rules/metadata.md
@@ -5,7 +5,7 @@ disableToc: false
 chapter: false
 ---
 
-{{% notice note %}}
+{{% notice style="note" icon="clock-rotate-left" %}}
 **The content on this page may be outdated.** We are currently in the process of rewriting all of our documentation: please bear with us while we update our older content.
 {{% /notice %}}
 

diff --git a/content/3-about-rules/ruleid.md b/content/3-about-rules/ruleid.md
@@ -5,7 +5,7 @@ disableToc: false
 chapter: false
 ---
 
-{{% notice note %}}
+{{% notice style="note" icon="clock-rotate-left" %}}
 **The content on this page may be outdated.** We are currently in the process of rewriting all of our documentation: please bear with us while we update our older content.
 {{% /notice %}}
 

diff --git a/content/4-about-plugins/4-1-plugins.md b/content/4-about-plugins/4-1-plugins.md
@@ -8,7 +8,7 @@ aliases: ["../concepts/plugins"]
 
 > The CRS plugin mechanism allows the rule set to be extended in specific, experimental, or unusual ways, as this page explains.
 
-{{% notice note %}}
+{{% notice style="note" icon="puzzle-piece" %}}
 Plugins are not part of the CRS 3.3.x release line. They are released officially with CRS 4.0. In the meantime, plugins _can_ be used with one of the stable releases by following the instructions presented below.
 {{% /notice %}}
 
@@ -73,7 +73,7 @@ crs/plugins/empty-after.conf
 
 These empty rule files ensure that the web server does not fail when `Include`-ing `*.conf` if there are no plugin files present.
 
-{{% notice info %}}
+{{% notice style="info" icon="server" %}}
 Apache supports the `IncludeOptional` directive, but that is not available on *all* web servers, so `Include` is used here in the interests of having consistent and simple documentation.
 {{% /notice %}}
 

diff --git a/content/5-advanced-topics/5-1-self-contained-mode.md b/content/5-advanced-topics/5-1-self-contained-mode.md
@@ -18,7 +18,7 @@ crs-setup.conf file usees the pass action:
 SecDefaultAction "phase:2,pass,log"
 ```
 
-{{% notice warning %}}
+{{% notice style="warning" icon="rotate-left" %}}
 From version 3.0 onwards, Anomaly Scoring is the default detection mode. Traditional detection mode is discouraged.
 {{% /notice %}}
 

diff --git a/content/5-advanced-topics/5-3-kubernetes-ingress-controller.md b/content/5-advanced-topics/5-3-kubernetes-ingress-controller.md
@@ -22,7 +22,7 @@ Refer to the [upstream installation guide](https://github.com/kubernetes/ingress
 
 The upstream project provides [many examples](https://github.com/kubernetes/ingress-nginx/tree/main/docs/examples) of how to configure the controller. These are a good starting point.
 
-{{% notice info %}}
+{{% notice style="info" icon="dharmachakra" %}}
 All of the configuration is done via the ConfigMap. All options for ModSecurity and CRS can be found in the [annotations list](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md#modsecurity).
 {{% /notice %}}
 

diff --git a/content/6-development/6-2-crs-toolchain.md b/content/6-development/6-2-crs-toolchain.md
@@ -36,7 +36,7 @@ crs-toolchain-2.7.0_amd64.deb: OK
 
 ### Method 2: Install with Go
 
-{{% notice note %}}
+{{% notice style="note" icon="code" %}}
 This method requires Go 1.19 or higher installed on your system.
 {{% /notice %}}
 
@@ -156,7 +156,7 @@ crs-toolchain <command> --help    # Show help for a specific command
 - Removed mage build tool dependency
 - Restricted evasion modifiers usage
 
-{{% notice tip %}}
+{{% notice style="tip" icon="code-branch" %}}
 To see the full release history and detailed changelogs, visit the [releases page](https://github.com/coreruleset/crs-toolchain/releases) on GitHub.
 {{% /notice %}}
 
@@ -244,7 +244,7 @@ The output will show:
 
 Updates rule files directly with newly generated expressions. This command modifies the actual CRS rule configuration files.
 
-{{% notice warning %}}
+{{% notice style="warning" icon="file-pen" %}}
 This command modifies files in place. Make sure you have committed your changes or have a backup before running update commands.
 {{% /notice %}}
 
@@ -418,7 +418,7 @@ crs-toolchain completion fish > ~/.config/fish/completions/crs-toolchain.fish
 crs-toolchain completion powershell | Out-String | Invoke-Expression
 ```
 
-{{% notice tip %}}
+{{% notice style="tip" icon="terminal" %}}
 After installing shell completion, you may need to restart your shell or source your shell configuration file for the changes to take effect.
 {{% /notice %}}