Apply suggestions from code review

Co-authored-by: Claire W <[email protected]>

Author: securitypedant

src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx

@@ -9,21 +9,21 @@ updated: 2024-12-11
 ---
 ## Introduction
 
-Security perimeters have become less defined compared to the traditional "Castle and Moat" deployment that were popular in the past. Within a fixed perimeter, it was relatively easier to secure multiple applications using a single Web Application Firewall (WAF) deployment inside a datacenter. Today this approach does not provide enough flexibility, as applications and services expand beyond the traditional datacenter. There are several good reasons to configure networks and services in a hybrid approach, as well as adopting SaaS platforms, so it is valuable to update the WAF approach to cover this scenario.
+Security perimeters have become less defined compared to the traditional "Castle and Moat" deployments that were popular in the past. Within a fixed perimeter, it was relatively easier to secure multiple applications using a single Web Application Firewall (WAF) deployment inside a datacenter. Today this approach does not provide enough flexibility as applications and services expand beyond the traditional datacenter. There are several good reasons to configure networks and services in a hybrid approach and to adopt SaaS platforms, so it is valuable to update the WAF approach to cover this scenario.
 
-In this sense, Cloud-based WAF solutions can control the perimeter sprawl, with a flexible deployment model that covers applications and services deployed on-premises, on cloud based IaaS and PaaS environments, and also in hybrid environments. 
+Cloud-based WAF solutions can control the perimeter sprawl with a flexible deployment model that covers applications and services deployed on-premises, on cloud-based IaaS and PaaS environments, and in hybrid environments. 
 
-At the same time, an incorrect implementation of a Cloud-based WAF can lead to security policy fragmentation and duplication, causing increased overheads both in maintenance and in monitoring. Aside from the clear economic impact that such inefficiencies bring, the lower efficiency can also degrade the security posture itself. This ultimately can lead to security incidents of varying degrees of severity depending on the scenario.
+At the same time, an incorrect implementation of a cloud-based WAF can lead to security policy fragmentation and duplication, causing increased overheads both in maintenance and in monitoring. Aside from the clear economic impact that such inefficiencies bring, the lower efficiency can also degrade the security posture itself. This ultimately can lead to security incidents of varying degrees of severity depending on the scenario.
 
 ### Who is this document for and what will you learn?
 
-This Design Guide is written for security and network administrators / architects that are looking to implement a flexible, Cloud-based WAF security configuration. This configuration can span across multiple applications, domains, and services - all deployed in a hybrid environment.
+This Design Guide is written for security and network administrators / architects that are looking to implement a flexible, cloud-based WAF security configuration. This configuration can span across multiple applications, domains, and services - all deployed in a hybrid environment.
 
-Cloudflare offers a comprehensive Application Security & Performance solutions, which include a highly-configurable, cloud-based Web Application Firewall (WAF).
+Cloudflare offers comprehensive Application Security & Performance solutions, which include a highly-configurable, cloud-based Web Application Firewall (WAF).
 
 In this guide, you will learn:
 
-* How to implement the Cloudflare WAF, and factor common rules. 
+* How to implement the Cloudflare WAF and factor common rules. 
 * How to easily implement common configurations across multiple applications.
 * How to deploy exceptions and specific configurations when needed.
 * What are the best practices to follow when deploying the Cloudflare WAF.
@@ -54,15 +54,15 @@ From a WAF setup perspective, this scenario raises interesting requirements:
 * To include a "catch-all" configuration, ensuring that a Cloudflare default WAF setup is always applied to all web traffic that does not fall in the above scenarios.
 * To minimize set up time and ongoing maintenance efforts, as applications are added and removed over time.
 
-In this Design Guide we will review how the Cloudflare WAF operates, and what tools are provided to achieve all the above architectural requirements.
+In this Design Guide we will review how the Cloudflare WAF operates and what tools are provided to achieve all the above architectural requirements.
 
 ## Cloudflare Web Application Firewall
 
-The Cloudflare WAF operates at both the zone and the account level. There are different [WAF phases](/ruleset-engine/about/phases/) (`http_request_firewall_custom`, `http_ratelimit` and `http_request_firewall_managed`) that map to Custom Rules, Rate Limiting Rules and Managed Rules. These phases exist both at the account and the zone level. For more information, please [refer to the following documentation](/waf/reference/phases/). It is important to note that the Account rulesets are evaluated before the zone rulesets.
+The Cloudflare WAF operates at both the zone and the account level. There are different [WAF phases](/ruleset-engine/about/phases/) (`http_request_firewall_custom`, `http_ratelimit` and `http_request_firewall_managed`) that map to Custom Rules, Rate Limiting Rules, and Managed Rules. These phases exist both at the account and the zone level. For more information, please [refer to the following documentation](/waf/reference/phases/). It is important to note that the Account rulesets are evaluated before the zone rulesets.
 
 ## Example Use Case - Implementing the Cloudflare Managed Ruleset
 
-For the purposes of this guide, we will build on the example scenario and WAF Requirements provided above. You have a single Cloudflare Account (or Enterprise Organization), and two 2nd level domains onboarded on it.
+For the purposes of this guide, we will build on the example scenario and WAF Requirements provided above. You have a single Cloudflare Account (or Enterprise Organization) and two 2nd level domains onboarded on it.
 
 Let's imagine that there are six applications behind six FQDNs across two domains. For these applications, you want to apply a baseline WAF security posture. However, of these six applications, two will require a more special treatment:
 
@@ -75,15 +75,15 @@ Let's visualize the scenario below:
 
 ### Using Account Level WAF to minimize configuration overheads
 
-We will use the [Cloudflare Managed Ruleset](/waf/managed-rules/reference/cloudflare-managed-ruleset/) as an example, keeping in mind that the approach can also be used for other Cloudflare Managed Rules, Rate Limiting Rules and Custom Rules.
+We will use the [Cloudflare Managed Ruleset](/waf/managed-rules/reference/cloudflare-managed-ruleset/) as an example, keeping in mind that the approach can also be used for other Cloudflare Managed Rules, Rate Limiting Rules, and Custom Rules.
 
 * For `web1.example.com`, `web2.example.com`, `web3.example.com` and `web5.example.org`: you want to apply the default WAF Managed Ruleset, already tuned by Cloudflare.
 * For `special4.example.com`: you want to apply a different subset of the default Managed Ruleset, as you already identified a couple of rules that are causing false positives on the legacy application.
 * For `special6.example.org`: you want to apply the Managed Ruleset in logging mode, as this is a newly introduced application from a third party and you need to start evaluating how to protect it.
 
 Then, you can adopt the following approach:
 
-* Deploy one instance of the Cloudflare Managed Ruleset, at the Account Level. This implements the common subset of rules for the four FQDNS requiring it. This is easier to set up and maintain than replicating the same configuration four times at the Zone level.
+* Deploy one instance of the Cloudflare Managed Ruleset at the Account Level. This implements the common subset of rules for the four FQDNS requiring it. This is easier to set up and maintain than replicating the same configuration four times at the Zone level.
 * For `special4.example.com` and `special6.example.org`, you will deploy two additional instances of the Managed Ruleset, with the specific tweaks required by the applications behind these particular FQDNs.
 
 In practice, using the [Account Level WAF's Managed rulesets](/waf/account/managed-rulesets/), you can deploy the three instances of our Managed Ruleset. Each instance will have its own [Custom Filter Expression](/ruleset-engine/rules-language/expressions/edit-expressions/), which will check that the HTTPS requests's hostname belongs to one of the FQDNs in a list:
@@ -96,7 +96,7 @@ Let's visualize the complete configuration in the below diagram:
 
 ![Diagram depicting the implemented WAF configuration at the account level](~/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-3.svg "Figure 3: The Account WAF implementation to protect multiple applications across different hostnames with repeatable configurations.")
 
-This setup will provide three instances of the "Managed Ruleset", calibrated for each application group. 
+This setup will provide three instances of the Managed Ruleset, calibrated for each application group. 
 
 If you have additional applications to be protected in the future, it is sufficient to include the new application FQDN to the filter expression. Generally, most will be added to the standard ruleset instance that is using the recommended Cloudflare configuration. Another common strategy is to add new applications to the `Log` mode instance, so that it can be monitored and eventually transitioned to the `Default` mode ruleset or to a more specific variation if required.
 
@@ -117,32 +117,32 @@ This approach can be simpler when there are few exceptions to the norm, and when
 ### Using Lists
 Cloudflare provides the ability to create [lists of hostnames](/waf/tools/lists/create-dashboard/). In this case, the Filter expression can be changed to reference such list variables. 
 
-You can then update the lists directly and re-use them across multiple rulesets. For example, use the same list for the Cloudflare Managed Rules but also for the OWASP Ruleset and Rate Limiting. Your filters [will reference the lists directly](/waf/tools/lists/use-in-expressions/), meaning a cleaner and maintainable configuration.
+You can then update the lists directly and re-use them across multiple rulesets. For example, use the same list for the Cloudflare Managed Rules and also for the OWASP Ruleset and Rate Limiting. Your filters [will reference the lists directly](/waf/tools/lists/use-in-expressions/), meaning a cleaner and maintainable configuration.
 
 When using lists, it is also much easier to adopt a "catch all rule" that runs last in the evaluation order. This could implement, for example, the `Default` Cloudflare Managed Ruleset when the host in the HTTPS request is not included in any of your lists. This ensures that a default WAF Managed Rules configuration is always applied, in case some of your applications are not added by mistake to the lists.
 
 ### Using automations
 
 The WAF configuration can be managed [via API calls](/api/) and [Terraform](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs). This is particularly useful when you want to scale the approach to many more zones and FQDNs, and to avoid repetitive and manual tasks in the Dashboard.
 
-For example, a default Terraform configuration file could be created to define Rulesets and Lists, and then maintained and applied as needed without needing to make changes in the Cloudflare Dashboard.
+For example, a default Terraform configuration file could be created to define Rulesets and Lists and then maintained and applied as needed without needing to make changes in the Cloudflare Dashboard.
 
 ### Avoid mixing setup at Account and Zone level
 
-When possible, Cloudflare recommends to maintain the configuration at the Account level, in particular when a Cloudflare Zone will contain multiple DNS records, each requiring custom configuration.
+When possible, Cloudflare recommends maintaining the configuration at the Account level, in particular when a Cloudflare Zone will contain multiple DNS records, each requiring custom configuration.
 
 At the Zone level WAF, you can deploy only one instance of each ruleset (Managed Rules, OWASP Rules, etc.), and therefore handling special scenarios can be more complex or not possible at this level.
 
 ### Custom Rules and Rate Limiting Rules
 
-The approach described above for Managed Rules can be applied also to [Custom](/waf/account/custom-rulesets/) and [Rate Limiting](/waf/account/rate-limiting-rulesets/), extending the flexibility to all the WAF security tools at your disposal.
+The approach described above for Managed Rules can be applied also to [Custom Rulesets](/waf/account/custom-rulesets/) and [Rate Limiting](/waf/account/rate-limiting-rulesets/), extending the flexibility to all the WAF security tools at your disposal.
 
-Unless your configuration is specific to a single zone, Cloudflare recommends to implement it at the Account level.
+Unless your configuration is specific to a single zone, Cloudflare recommends implementing it at the Account level.
 
-For more information, please refer to the Cloudflare Documentation:
+For more information, please refer to the following resources:
 * [Create a Rate Limiting Rule at the Account level](/waf/account/rate-limiting-rulesets/create-dashboard/)
 * [Create Custom Rulesets at the Account level](/waf/account/custom-rulesets/)
 
 ## Summary
 
-In conclusion, this design guide illustrates how you can implement flexible WAF configurations covering multiple applications and domains. The described approach reduces the effort required to deploy, maintain and update your WAF security configuration.
+In conclusion, this design guide illustrates how you can implement flexible WAF configurations to cover multiple applications and domains. The described approach reduces the effort required to deploy, maintain, and update your WAF security configuration.