Rethinking how the Cloudflare WAF is configured
The Cloudflare Web Application Firewall (WAF) shields websites and applications from malicious traffic that seeks to exploit server-side vulnerabilities. As a central part of an application’s security posture, the WAF’s dashboard experience needed to make it straightforward to activate the service and tailor rules to an application’s specific needs. This post outlines the design process behind the new Cloudflare Web Application Firewall dashboard, focusing on how we identified user tasks, prioritized them, and translated those findings into interface improvements.
Our approach to redesigning the WAF dashboard followed three stages:
- Identify the tasks customers aim to complete with the WAF.
- Prioritize those tasks based on frequency and importance.
- Define, create, and refine the interface and interactions.
Understanding customer workflows
Cloudflare serves a broad spectrum of users, from individual developers and hobbyists to small and medium businesses where one person may wear many hats, to large enterprises with dedicated security teams. Traditional product development methods like user personas or user stories fall short here. Personas often rely on demographic averages and fail to explain why a user chooses a feature. User stories mix personas with implementation details and desired outcomes without adequately describing the user’s situation.
To better empathize with this diverse range, we used Job Stories, which center on the user’s situation, motivation, and desired outcome. We interviewed customers directly and supplemented those sessions with input from our Solutions Engineering team, whose members work with many customers daily and can aggregate feedback across them. From these interviews we identified several recurring job stories:
- When onboarding with Cloudflare, I want to quickly turn on the WAF and use the default settings so I can move on to configuring other Cloudflare features.
- When refining and tuning my zone’s configuration, I only want to configure the rules I’m interested in so I can avoid false positives.
We then analyzed each use case to see what worked in the legacy interface and what created confusion or inefficiency.
Turning on the WAF with defaults
With the legacy dashboard, activating a managed ruleset like Cloudflare Managed Ruleset or OWASP ModSecurity Core Rule Set required tedious configuration. A customer had to enable at least two switches: the overall WAF toggle and at least one group within the chosen managed ruleset. Because these were separate options, customers could easily misconfigure the WAF into a vulnerable state — enabling rule groups while the master WAF switch remained off. That configuration would be silently ignored, leaving the application unprotected. This represented our first major improvement opportunity: the journey to enable the WAF should be simple and safe.
Configuring only relevant rules
In the legacy Managed Rules page, rule groups were listed directly under each ruleset card, making it easy to enable or disable a specific group — a common workflow we observed in research. However, drilling into a group revealed a new problem. Each group consists of individual rules, and opening a group showed a modal with its rules. The legacy UI made it trivial to change the action of a single rule via a dropdown. That’s fine for one or two rules, but some groups contain hundreds. Configuring a complex WAF setup often demanded changing the action of every rule individually — hundreds of clicks, or resorting to API calls. This became our second area to improve: building tools for bulk edits and easier rule selection.
In short, users wanted a frictionless way to turn on the WAF, but the legacy process was cumbersome and error-prone. Conversely, toggling a single rule was simple, but making bulk changes across many rules was a substantial time sink.
Prioritizing which tasks to optimize
Using our telemetry and analytics tools, we determined how often customers perform each job story — a critical step for deciding which workflows deserved interface optimization. Data showed that about 76% of zones using the WAF run with its default configuration. This suggests most customers simply turn on the WAF and proceed to handle other Cloudflare features. It underscores the value of strong defaults: users tend to follow the path of least resistance, so defaults should be designed with the most common use cases in mind. The Cloudflare Managed Ruleset’s default state therefore exceeds the security requirements of most applications while maintaining a relatively low rate of false positives.
Designing and refining the interface
Using Figma and our Component Library, we rapidly created mockups and iterated through numerous designs.
Our research showed that enabling a ruleset needed to be dramatically simpler than the legacy experience, which was both complicated and error-prone. A core goal of our design is making complex configuration ridiculously simple while instilling confidence in the actions performed. With the new Managed Rules, enabling a ruleset like Cloudflare Managed Ruleset now takes a single click.
Next, we tackled the pain of making all rules execute the same action. Previously this required manually setting each rule’s dropdown. Now, the Managed Rules page offers a Ruleset Action — an action that all rules within a ruleset follow, configurable in one place.
For more granular control, we also improved bulk editing through the Rule Browser. Customers can browse all rules within a ruleset, select multiple rules using the checkboxes on the left-hand side, and set the action or status for the entire selection at once.
These interactions did not emerge fully formed. They were the product of many design critiques and constant evaluation against the identified job stories. We plan to use telemetry and analytics to understand how customers engage with the new capabilities and will keep refining the experience to serve them more effectively.
