chore: update theme

.github/workflows/gh-pages.yml

@@ -32,7 +32,7 @@ jobs:
   build:
     runs-on: ubuntu-latest
     env:
-      HUGO_VERSION: 0.122.0
+      HUGO_VERSION: 0.135.1
     steps:
       - name: Install Hugo CLI
         run: |

.github/workflows/test.yml

@@ -20,7 +20,8 @@ jobs:
   syntax-check:
     runs-on: ubuntu-latest
     env:
-      HUGO_VERSION: 0.124.1
+      # renovate: datasource=github-releases depName=gohugo/hugo
+      HUGO_VERSION: 0.135.0
     steps:
       - name: Install Hugo CLI
         run: |

config/_default/config.toml

@@ -5,17 +5,15 @@ theme = "hugo-relearn"
 
 # For search functionality
 [outputs]
-home = [ "HTML", "RSS", "JSON"]
+home = ['html', 'rss', 'print']
 
 [params]
   # Prefix URL to edit current page. Will display an "Edit this page" button on top right hand corner of every page.
   # Useful to give opportunity to people to create merge request for your doc.
   # See the config.toml file from this documentation site to have an example.
   editURL = "https://github.com/coreruleset/documentation/blob/main/content/"
   # Author of the site, will be used in meta information
-  author = "CRS project"
-  # Description of the site, will be used in meta information
-  description = "CRS Documentation"
+  author.name = "CRS project"
   # Shows a checkmark for visited pages on the menu
   showVisitedLinks = true
   # Disable search function. It will hide search bar

content/_index.md

@@ -1,5 +1,6 @@
 ---
 title: "CRS Documentation"
+description: "CRS Documentation"
 ---
 
 > OWASP CRS provides documentation for many of the aspects surrounding the project. This page provides an overview of the project and its documentation.
@@ -14,7 +15,7 @@ OWASP® (Open Worldwide Application Security Project) CRS (previously Core Rule
 
 ## How to Get Involved
 
-For information on how to join the vibrant community of CRS developers, start by checking out the project's [GitHub repository](https://github.com/coreruleset/coreruleset). When ready to make a contribution, have a read of the project's [contribution guidelines]({{< ref "development/contribution_guidelines/" >}}) which are used to keep the project consistent, well managed, and of a high quality.
+For information on how to join the vibrant community of CRS developers, start by checking out the project's [GitHub repository](https://github.com/coreruleset/coreruleset). When ready to make a contribution, have a read of the project's [contribution guidelines]({{% ref "development/contribution_guidelines/" %}}) which are used to keep the project consistent, well managed, and of a high quality.
 
 ## CRS Change Policy
 

content/concepts/false_positives_tuning.md

@@ -11,7 +11,7 @@ chapter: false
 
 CRS provides _generic_ attack detection capabilities. A fresh CRS deployment has no awareness of the web services that may be running behind it, or the quirks of how those services work. It is possible that *genuine* transactions may cause some CRS rules to match in error, if the transactions happen to match one of the generic attack behaviors or patterns that are being detected. Such a match is referred to as a *false positive*, or false alarm.
 
-False positives are particularly likely to happen when operating at higher [paranoia levels]({{< ref "paranoia_levels" >}} "Page describing paranoia levels."). While paranoia level 1 is designed to cause few, ideally zero, false positives, higher paranoia levels are increasingly likely to cause false positives. Each successive paranoia level introduces additional rules, with *higher* paranoia levels adding *more aggressive* rules. As such, the higher the paranoia level is the more likely it is that false positives will occur. That is the cost of the higher security provided by higher paranoia levels: the additional time it takes to tune away the increasing number of false positives.
+False positives are particularly likely to happen when operating at higher [paranoia levels]({{% ref "paranoia_levels" %}} "Page describing paranoia levels."). While paranoia level 1 is designed to cause few, ideally zero, false positives, higher paranoia levels are increasingly likely to cause false positives. Each successive paranoia level introduces additional rules, with *higher* paranoia levels adding *more aggressive* rules. As such, the higher the paranoia level is the more likely it is that false positives will occur. That is the cost of the higher security provided by higher paranoia levels: the additional time it takes to tune away the increasing number of false positives.
 
 ### Example False Positive
 
@@ -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 %}}
-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. 
+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 %}}
 
 ### Why are False Positives a Problem?
@@ -102,7 +102,7 @@ In addition to the two *types* of exclusions, rules can be excluded in two diffe
 - **Exclude the entire rule/tag:** An entire rule, or entire category of rules (by specifying a tag), is removed and will not be executed by the rule engine.
 - **Exclude a specific variable from the rule/tag:** A *specific variable* will be excluded from a specific rule, or excluded from a category of rules (by specifying a tag).
 
-These two methods can also operate on multiple individual rules, or even entire rule categories (identified either [by tag]({{< ref "#rule-tags" >}}) or by using a [range of rule IDs]({{< ref "#rule-ranges" >}})). 
+These two methods can also operate on multiple individual rules, or even entire rule categories (identified either [by tag]({{% ref "#rule-tags" %}}) or by using a [range of rule IDs]({{% ref "#rule-ranges" %}})). 
 
 The combinations of rule exclusion types and methods allow for writing rule exclusions of varying granularity. Very coarse rule exclusions can be written, for example "remove all SQL injection rules" using `SecRuleRemoveByTag`. Extremely granular rule exclusions can also be written, for example "for transactions to the location 'web_app_2/function.php', exclude the query string parameter 'user_id' from rule 920280" using a SecRule and the action `ctl:ruleRemoveTargetById`.
 

content/concepts/paranoia_levels.md

@@ -78,7 +78,7 @@ There is a better solution. First, think of the paranoia level as being the "blo
 
 *Example: Blocking paranoia level of 1 and executing paranoia level of 2*
 
-![Diagram showing a scenario where the blocking paranoia level and the executing paranoia level are different. The active and inactive paranoia levels are emphasized to explain the concept.](https://coreruleset.org/assets/uploads/2021/10/executing-paranoia-level-1.png?width=25em)
+![Diagram showing a scenario where the blocking paranoia level and the executing paranoia level are different. The active and inactive paranoia levels are emphasized to explain the concept.](https://coreruleset.org/images/2021/10/executing-paranoia-level-1.png?width=25em)
 
 **The executing paranoia level allows rules from a higher paranoia level to be run, and potentially to trigger false positives, without increasing the probability of blocking legitimate users.** Any new false positives can then be tuned away using rule exclusions. Once ready and with all the new rule exclusions in place, the blocking paranoia level can then be raised to match the executing paranoia level. This approach is a flexible and secure way to raise the paranoia level on a working production system *without* the risk of new false positives blocking users in error.
 

content/concepts/plugins.md

@@ -161,7 +161,7 @@ Available plugins include:
 
 ## How to Write a Plugin
 
-For information on writing a new plugin, refer to the development documentation on [writing plugins]({{< ref "plugin_writing.md" >}}).
+For information on writing a new plugin, refer to the development documentation on [writing plugins]({{% ref "plugin_writing.md" %}}).
 
 ## Collection Timeout
 

content/deployment/extended_install.md

@@ -5,7 +5,7 @@ disableToc: false
 chapter: false
 ---
 
-> All the information needed to properly install CRS is presented on this page. The installation concepts are expanded upon and presented in more detail than the [quick start guide]({{< ref "install.md" >}}).
+> All the information needed to properly install CRS is presented on this page. The installation concepts are expanded upon and presented in more detail than the [quick start guide]({{% ref "install.md" %}}).
 
 ## Contact Us
 
@@ -176,7 +176,7 @@ At a minimum, keep in mind the following:
 
 - CRS does not configure features such as the rule engine, audit engine, logging, etc. This task is part of the initial *engine* setup and is not a job for the rule set. For ModSecurity, if not already done, see the [recommended configuration](https://github.com/owasp-modsecurity/ModSecurity/blob/master/modsecurity.conf-recommended).
 - Decide what ModSecurity should do when it detects malicious activity, e.g., drop the packet, return a *403 Forbidden* status code, issue a redirect to a custom page, etc.
-- Make sure to configure the anomaly scoring thresholds. For more information see [Anomaly]({{< ref "anomaly_scoring.md" >}} "Anomaly").
+- Make sure to configure the anomaly scoring thresholds. For more information see [Anomaly]({{% ref "anomaly_scoring.md" %}} "Anomaly").
 - By default, the CRS rules will consider many issues with different databases and languages. If running in a specific environment, e.g., without any SQL database services present, it is probably a good idea to limit this behavior for performance reasons.
 - Make sure to add any HTTP methods, static resources, content types, or file extensions that are needed, beyond the default ones listed.
 
@@ -191,7 +191,7 @@ In addition to `crs-setup.conf.example`, there are two other ".example" files wi
 - `rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example`
 - `rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example`
 
-These files are designed to provide the rule maintainer with the ability to modify rules (see [false positives and tuning]({{< ref "../concepts/false_positives_tuning.md" >}}#rule-exclusions)) without breaking forward compatibility with rule set updates. These two files should be renamed by removing the `.example` suffix. This will mean that installing updates will *not* overwrite custom rule exclusions. To rename the files in Linux, use a command similar to the following:
+These files are designed to provide the rule maintainer with the ability to modify rules (see [false positives and tuning]({{% ref "#rule-exclusions" %}})) without breaking forward compatibility with rule set updates. These two files should be renamed by removing the `.example` suffix. This will mean that installing updates will *not* overwrite custom rule exclusions. To rename the files in Linux, use a command similar to the following:
 
 ```bash
 mv rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
@@ -202,7 +202,7 @@ mv rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example rules/RESPONSE-999-
 
 The engine should support the `Include` directive out of the box. This directive tells the engine to parse *additional* files for directives. The question is where to put the CRS rules folder in order for it to be included.
 
-Looking at the CRS files, there are quite a few ".conf" files. While the names attempt to do a good job at describing what each file does, additional information is available in the [rules]({{< ref "../rules/" >}}) section.
+Looking at the CRS files, there are quite a few ".conf" files. While the names attempt to do a good job at describing what each file does, additional information is available in the [rules]({{% ref "rules" %}}) section.
 
 ### Includes for Apache
 

content/deployment/install.md

@@ -5,7 +5,7 @@ disableToc: false
 chapter: false
 ---
 
-This guide aims to get a CRS installation up and running. This guide assumes that a compatible ModSecurity engine is already present and working. If unsure then refer to the [extended install]({{< ref "extended_install.md" >}}) page for full details.
+This guide aims to get a CRS installation up and running. This guide assumes that a compatible ModSecurity engine is already present and working. If unsure then refer to the [extended install]({{% ref "extended_install.md" %}}) page for full details.
 
 ## Downloading the Rule Set
 
@@ -73,7 +73,7 @@ gpg: Good signature from "OWASP CRS <security@coreruleset.org>" [ultimate]
 
 Once the rule set has been downloaded and verified, extract the rule set files to a well known location on the server. This will typically be somewhere in the web server directory.
 
-The examples presented below demonstrate using Apache. For information on configuring Nginx or IIS see the [extended install]({{< ref "install.md" >}}) page.
+The examples presented below demonstrate using Apache. For information on configuring Nginx or IIS see the [extended install]({{% ref "install.md" %}}) page.
 
 Note that while it's common practice to make a new `modsecurity.d` folder, as outlined below, this isn't strictly necessary. The path scheme outlined is common on RHEL-based operating systems; the Apache path used may need to be adjusted to match the server's installation.
 
@@ -103,7 +103,7 @@ mv crs-setup.conf.example crs-setup.conf
 
 ### Include-ing the Rule Files
 
-The last step is to tell the web server where the rules are. This is achieved by `include`-ing the rule configuration files in the `httpd.conf` file. Again, this example demonstrates using Apache, but the process is similar on other systems (see the [extended install]({{< ref "install.md" >}}) page for details).
+The last step is to tell the web server where the rules are. This is achieved by `include`-ing the rule configuration files in the `httpd.conf` file. Again, this example demonstrates using Apache, but the process is similar on other systems (see the [extended install]({{% ref "install.md" %}}) page for details).
 
 ```bash
 echo 'IncludeOptional {{< param crs_install_dir >}}/crs-setup.conf' >> /etc/httpd/conf/httpd.conf
@@ -113,15 +113,15 @@ echo 'IncludeOptional {{< param crs_install_dir >}}/rules/*.conf' >> /etc/httpd/
 echo 'IncludeOptional {{< param crs_install_dir >}}/plugins/*-after.conf' >> /etc/httpd/conf/httpd.conf
 ```
 
-Now that everything has been configured, it should be possible to restart and begin using the OWASP CRS. The CRS rules typically require a bit of tuning with rule exclusions, depending on the site and web applications in question. For more information on tuning, see [false positives and tuning]({{< ref "false_positives_tuning.md" >}}).
+Now that everything has been configured, it should be possible to restart and begin using the OWASP CRS. The CRS rules typically require a bit of tuning with rule exclusions, depending on the site and web applications in question. For more information on tuning, see [false positives and tuning]({{% ref "false_positives_tuning.md" %}}).
 
 ```bash
 systemctl restart httpd.service
 ```
 
 ## Alternative: Using Containers
 
-Another quick option is to use the official CRS [pre-packaged containers]({{< ref "../development/useful_tools/#official-crs-maintained-docker-images" >}}). Docker, Podman, or any compatible container engine can be used. The official CRS images are published in the Docker Hub. The image most often deployed is `owasp/modsecurity-crs`: it already has everything needed to get up and running quickly.
+Another quick option is to use the official CRS [pre-packaged containers]({{% ref "../development/useful_tools/#official-crs-maintained-docker-images" %}}). Docker, Podman, or any compatible container engine can be used. The official CRS images are published in the Docker Hub. The image most often deployed is `owasp/modsecurity-crs`: it already has everything needed to get up and running quickly.
 
 The CRS project pre-packages both Apache and Nginx web servers along with the appropriate corresponding ModSecurity engine. More engines, like [Coraza](https://coraza.io/), will be added at a later date.
 
@@ -171,7 +171,7 @@ Depending on your configurated thresholds, this should be detected as a maliciou
 
 ### Upgrading from CRS 3.x to CRS 4
 
-The most impactful change is the removal of application exclusion packages in favor of a plugin system. If you had activated the exclusion packages in CRS 3, you should download the plugins for them and place them in the plugins subdirectory. We maintain the list of plugins in our [Plugin Registry](https://github.com/coreruleset/plugin-registry). You can find detailed information on working with plugins in our [plugins documentation]({{< ref "plugins.md" >}}).
+The most impactful change is the removal of application exclusion packages in favor of a plugin system. If you had activated the exclusion packages in CRS 3, you should download the plugins for them and place them in the plugins subdirectory. We maintain the list of plugins in our [Plugin Registry](https://github.com/coreruleset/plugin-registry). You can find detailed information on working with plugins in our [plugins documentation]({{% ref "plugins.md" %}}).
 
 In terms of changes to the detection rules, the amount of changes is smaller than in the CRS 2—3 changeover. Most rules have only evolved slightly, so it is recommended that you keep any existing custom exclusions that you have made under CRS 3.