fix: typos in waf content

content/includes/waf/policy.html

@@ -378,7 +378,7 @@ <h1 id="policy">policy</h1>
 <td><a href="#policy/signature-sets">signature-sets</a></td>
 <td>Yes</td>
 <td>array of objects</td>
-<td>Defines behavior when signatures found within a signature-set are detected in a request. Settings are culmulative, so if a signature is found in any set with block enabled, that signature will have block enabled.</td>
+<td>Defines behavior when signatures found within a signature-set are detected in a request. Settings are cumulative, so if a signature is found in any set with block enabled, that signature will have block enabled.</td>
 <td></td>
 </tr>
 <tr class="even">
@@ -3847,7 +3847,7 @@ <h2 id="policy/parameters">parameters</h2>
 <li><strong>pipe</strong>: pipe-separated values. Array color=["blue","black"] -&gt; color=blue|black.</li>
 <li><strong>form</strong>: ampersand-separated values. Array color=["blue","black"] -&gt; color=blue,black.</li>
 <li><strong>matrix</strong>: semicolon-prefixed values. Array color=["blue","black"] -&gt; ;color=blue,black.</li>
-<li><strong>tsv</strong>: tab-separated values. Array color=["blue","black"] -&gt; color=bluetblack.</li>
+<li><strong>tsv</strong>: tab-separated values. Array color=["blue","black"] -&gt; color=blue	black.</li>
 <li><strong>csv</strong>: comma-separated values. Array color=["blue","black"] -&gt; color=blue,black.</li>
 <li><strong>label</strong>: dot-prefixed values. Array color=["blue","black"] -&gt; .blue.black.</li>
 <li><strong>multi</strong>: multiple parameter instances rather than multiple values. Array color=["blue","black"] -&gt; color=blue&amp;color=black.</li>

content/waf/configure/nginx-features.md

@@ -20,7 +20,7 @@ Certain features do not work well with NGINX, such as modules requiring _subrequ
 
 Modules requiring the _Range_ header (Such as _Slice_) are also unsupported in a scope which enables F5 WAF for NGINX.
 
-The examples below show work arounds for the limitations of these features.
+The examples below show workarounds for the limitations of these features.
 
 For information on configuring NGINX, you should view the [NGINX documentation]({{< ref "/nginx/" >}}).
 

content/waf/configure/secure-mtls.md

@@ -82,7 +82,7 @@ stream {
     }
 ```
 
-- _upstream enforcer_ specifices the server, which listens on port 4431 by default
+- _upstream enforcer_ specifies the server, which listens on port 4431 by default
 - _proxy_pass_ indicates that requests should be routed through the enforcer upstream
 - _proxy_ssl_certificate_ and _proxy_ssl_certificate_key_ are for the client (NGINX) credentials
 - _proxy_ssl_trusted_certificate_ enables the server (enforcer) verification

content/waf/install/disconnected-environment.md

@@ -30,11 +30,11 @@ To complete this guide, you will need the following prerequisites:
 
 These instructions outline the broad, conceptual steps involved with working with a disconnected environment. You will need to make adjustments based on your specific security requirements.
 
-Some users may be able to use a USB stick to transfer necessary set-up artefacts, whereas other users may be able to use tools such as SSH or SCP.
+Some users may be able to use a USB stick to transfer necessary set-up artifacts, whereas other users may be able to use tools such as SSH or SCP.
 
-In the following sections, the term _connected environment_ refers to the environment with access to the internet you will use to download set-up artefacts.
+In the following sections, the term _connected environment_ refers to the environment with access to the internet you will use to download set-up artifacts.
 
-The term _disconnected environment_ refers to the final environment the F5 WAF for NGINX installation is intended to run in, and is the target to transfer set-up artefacts from the connected environment.
+The term _disconnected environment_ refers to the final environment the F5 WAF for NGINX installation is intended to run in, and is the target to transfer set-up artifacts from the connected environment.
 
 ## Download and run the documentation website locally
 

content/waf/install/docker.md

@@ -35,7 +35,7 @@ There are three kinds of Docker deployments available:
 - Hybrid configuration
 - Single container configuration
 
-The multi-container configuration is recommended if you are building a new system, and deploys the F5 for WAF module and its components in seperate images, allowing for nuanced version management.
+The multi-container configuration is recommended if you are building a new system, and deploys the F5 for WAF module and its components in separate images, allowing for nuanced version management.
 
 The hybrid configuration is suitable if you want to add F5 WAF for NGINX to an existing virtual environment and wish to use Docker for the F5 WAF components instead of installing and configuring WAF packages as explained in the [Virtual machine or bare metal]({{< ref "/waf/install/virtual-environment.md" >}}) instructions.
 
@@ -486,7 +486,7 @@ sudo apk add openssl ca-certificates app-protect-module-plus
 
 Create a file for the F5 WAF for NGINX repository:
 
-**/etc/yum.repos.d/app-protect-x-oss.repoo**
+**/etc/yum.repos.d/app-protect-x-oss.repo**
 
 ```shell
 [app-protect-x-oss]

content/waf/install/kubernetes-plm.md

@@ -24,7 +24,7 @@ There are two new features available for Kubernetes through early access:
 
 <!-- Policy lifecycle management (PLM) is a system for managing, compiling and deploying security policies in Kubernetes environments.  -->
 
-They extends the WAF compiler capabilities by providing a native Kubernetes operater-based approach for policy orchestration.
+They extends the WAF compiler capabilities by providing a native Kubernetes operator-based approach for policy orchestration.
 
 These feature revolve around a _Policy Controller_ which uses the Kubernetes operator pattern to manage the lifecycle of WAF security artifacts. 
 

content/waf/logging/security-logs.md

@@ -98,7 +98,7 @@ Content is mandatory. If the entire content field or any of its attributes are n
 
 #### Default logging content
 
-This is the content of `log_default.json`. It is pre-compield (built-in) and is used by default when `app_protect_security_log_enabled on` is set, but `app_protect_security_log` is not:
+This is the content of `log_default.json`. It is pre-compiled (built-in) and is used by default when `app_protect_security_log_enabled on` is set, but `app_protect_security_log` is not:
 
 ```json
 {
@@ -228,7 +228,7 @@ The table below lists attributes that are generated in the security logs. When u
 | bot_anomalies | Comma-separated list of anomalies that were detected. | default, grpc |
 | bot_category | The category of the detected bot. | default, grpc |
 | bot_signature_name | The name of the detected bot. | default, grpc |
-| client_class | The classification of the client. It can have one of the following values: `N/A`, `Suspicious Browser`, `Malicous Bot`, `Trusted Bot`, `Untrusted Bot`. If the client is classified as standard browser, then the value is `N/A`. | default, grpc |
+| client_class | The classification of the client. It can have one of the following values: `N/A`, `Suspicious Browser`, `Malicious Bot`, `Trusted Bot`, `Untrusted Bot`. If the client is classified as standard browser, then the value is `N/A`. | default, grpc |
 | date_time | The date and time the request was received by App Protect. | default, grpc |
 | dest_port | The port assigned to listen to incoming requests. | default, grpc |
 | enforced_bot_anomalies | Comma-separated list of anomalies that caused the request to be blocked. | default, grpc |

content/waf/policies/attack-signatures.md

@@ -81,7 +81,7 @@ Since the "All Signatures" set is not included in the default policy, turning OF
 
 The only way to remove signature sets is to remove or disable sets that are part of the [default policy]({{< ref "/waf/policies/configuration.md#default-policy" >}}).
 
-For example, in the below default policy, even though all signature alarm and block settings are set to false, attack signatures enforcement cannot be ignoredas some of the signature sets will be enabled in their strict policy. 
+For example, in the below default policy, even though all signature alarm and block settings are set to false, attack signatures enforcement cannot be ignored as some of the signature sets will be enabled in their strict policy. 
 
 If you want to remove a specific signature set, you must explicitly mention it under the [strict policy]({{< ref "/waf/policies/configuration.md#strict-policy" >}}).
 

content/waf/policies/configuration.md

@@ -29,7 +29,7 @@ The [Build and use the compiler tool]({{< ref "/waf/configure/compiler.md" >}})
 | Feature        | Description |
 | -------------- | ----------- |
 | Blocking pages | The user can customize all blocking pages. By default the AJAX response pages are disabled, but the user can enable them. |
-| Enforcement by violation rating | By default block requests that are declared as threats, which are ated 4 or 5. It is possible to change this behavior: either disable enforcement by Violation Rating or block also request with Violation Rating 3 - needs examination. |
+| Enforcement by violation rating | By default block requests that are declared as threats, which are rated 4 or 5. It is possible to change this behavior: either disable enforcement by Violation Rating or block also request with Violation Rating 3 - needs examination. |
 | Large request blocking | To increase the protection of resources at both the NGINX Plus and upstream application tiers, all requests that are larger than 10 MB in size are blocked.  When these requests are blocked, a `VIOL_REQUEST_MAX_LENGTH` violation will be logged.|
 | Malformed cookie | Requests with cookies that are not RFC compliant are blocked by default. This can be disabled. |
 | Parameter parsing | Support only auto-detect parameter value type and acts according to the result: plain alphanumeric string, XML or JSON. |

content/waf/policies/data-guard.md

@@ -20,7 +20,7 @@ Examples include credit card numbers (CCN), Social Security numbers (SSN) or cus
 
 Sensitive data is either blocked or masked based on configuration.
 
-Thes following example enables _blocking mode_:
+The following example enables _blocking mode_:
 
 ```json
 {
@@ -90,7 +90,7 @@ Data masking allows a page to load while masking all sensitive data.
 
 This final example shows partial masking using a custom pattern.
 
-Custom patterns are defined in _customPatternsList_, with the numbers of unmaked leading and trailing characters defined by _firstCustomCharactersToExpose_ and _lastCustomCharactersToExpose_, respectively.
+Custom patterns are defined in _customPatternsList_, with the numbers of unmasked leading and trailing characters defined by _firstCustomCharactersToExpose_ and _lastCustomCharactersToExpose_, respectively.
 
 ```json
 {

content/waf/policies/deny-allow-ip.md

@@ -20,7 +20,7 @@ This feature allows you to define IP addresses or ranges for which the traffic w
 2. **Always Denied** (`"blockRequests": "always"`) - Requests from this IP range will be always blocked even if they have no other blocking violations. The `VIOL_BLACKLISTED_IP` violation will be triggered in this case and its block flag must be set to `true` in order for the request to be actually blocked.
 3. **Never Log** (`"neverLogRequests": true`) - Requests from this IP range will not be logged even if defined by logging configuration. This is independent of the other settings, so the same IP range can be both denied (or allowed) and yet never logged.
 
-In this IPv4 example, the default configuratio is used while enabling the deny list violation. The configuration section defines:
+In this IPv4 example, the default configuration is used while enabling the deny list violation. The configuration section defines:
 
 - An always allowed IP, 1.1.1.1
 - An always denied IP, 2.2.2.2

content/waf/policies/ip-intelligence.md

@@ -252,7 +252,7 @@ The following policy shows examples of both, with all IP intelligence categories
 ```json
 {
     "policy": {
-        "name": "ip_intelligency_policy",
+        "name": "ip_intelligence_policy",
         "template": {
             "name": "POLICY_TEMPLATE_NGINX_BASE"
         },

content/waf/policies/jwt-protection.md

@@ -137,7 +137,7 @@ Refer to the following example where all access profile properties are configure
 }
 ```
 
-{{< call-out "note" >}} For access profile default values and their related field names, see F5 WAF for NGINX [Policy paramenter reference]({{< ref "/waf/policies/parameter-reference.md" >}}). {{< /call-out >}}
+{{< call-out "note" >}} For access profile default values and their related field names, see F5 WAF for NGINX [Policy parameter reference]({{< ref "/waf/policies/parameter-reference.md" >}}). {{< /call-out >}}
 
 #### Access profile in URL settings
 
@@ -197,7 +197,7 @@ Only structure nesting is supported using the `.` notation.
 - Although it is possible to consolidate all conditions into one with `and`, it is not recommended. Splitting conditions improves readability and helps explain authorization failures.
 
 {{< call-out "note" >}}
-For the full reference of `authorizationRules` condition syntax and usage, see the F5 WAF for NGINX [Policy paramenter reference]({{< ref "/waf/policies/parameter-reference.md" >}}).
+For the full reference of `authorizationRules` condition syntax and usage, see the F5 WAF for NGINX [Policy parameter reference]({{< ref "/waf/policies/parameter-reference.md" >}}).
 {{< /call-out >}}
 
 See the example below for JWT claims: