F5XC – WAF Exclusion Policy

Project Vision

F5XC (Distributed Cloud) is a SaaS platform that provides unified management, security, and networking for applications deployed across multi-cloud, on-premises, and edge environments. Its web application firewall (WAF) service connects to load balancers (LBs) to protect applications by filtering, monitoring, and blocking malicious traffic. The WAF exclusion service allows specific parts of a web request to bypass inspection to prevent false positives and keep apps secure and accessible. However, the existing implementation did not allow reusing a WAF exclusion across multiple LBs, leading to inefficient configuration and repetitive workload for users. To solve this, we introduced a container called policy to group a set of WAF exclusion rules, making them sharable and reusable. The project began with HTTP LBs in the WAAP (Web App and API Protection) workspace and later expanded to the other three workspaces in the console.

Challenges

	Gain technical domain knowledge to inform effective design decisions
	Clarify complex use cases and refine unclear requirements, particularly for rule auto-generation.
	Enable users to navigate layers efficiently and easily access and control the feature.
	Streamline policy and rule configuration.

Current Issues & Project Goals

Clarify target user goals, usage scenarios, and reshape project scope.

Web application firewall (WAF) is a security solution that protects web applications from malicious traffic. It inspects all incoming requests, blocks harmful ones, and ensures only legitimate traffic reaches the server. It also helps organizations meet compliance requirements. While WAF exclusion allows specific parts of a web request to bypass inspection (e.g., headers, cookies, query parameters), preventing legitimate traffic from being mistakenly blocked due to false positives. It also allows customizing WAF behavior to fit an app’s unique structures and data, where cookies or values might conflict with standard WAF rules. Besides, it provides precise control, making WAF more robust against threats while minimizing restrictions on valid user interactions. Overall, WAF exclusion ensures the application stays accessible and functional without compromising security.

F5XC has three primary user groups: SecOps, NetOps, and DevOps. WAF exclusions are primarily targeted at SecOps users, who are responsible for mitigating security risks by detecting, triaging, and responding to incidents in real time.

Through kickoff meetings with PM, online research, and a review of PRD (product requirements document) and the current implementation, I learned that:

	Users typically review logs, identify issues (such as false positives), and create WAF exclusion rules to prevent them from recurring.
	WAF exclusions were not needed for every LB (,which distributes traffic across backend servers to improve availability, performance, and reliability by preventing overload and routing around unhealthy servers), but in certain cases, they were critical.
	Some scenarios (where a centralized security posture and consistent application behavior are required across a complex, multi-layered architecture – e.g., high-availability, multi-region, microservices deployments) required multiple LBs to share the same WAF exclusion configurations, but the system did not allow reuse.
	Routes within an LB, which distribute traffic to backend services based on defined rules, might also require their own WAF exclusions (when specific web applications behind the LB have unique behaviors that cause false positives or require less restrictive security), but this was not supported.

From this background, I gained a high-level understanding of the issues and project goals. In the current system, WAF exclusion rules could only be created under each HTTP LB configuration, with no way to share or reuse them. To solve this and improve the WAF exclusion experience, we introduced the concept of a WAF exclusion policy — a container for multiple rules that could be shared and reused across LBs and LB routes, with flexible connections to one, many, or none.

I later had further discussions with PM to clarify use cases and user stories (in problem-statement format), and involved design system (DS) team members early on so they could gain background knowledge and contribute effectively to design discussions and reviews later.

With clear problem statements in place, I mapped usage scenarios to the current user flow, identified issues, and translated user needs into design requirements aligned with the existing system structure:

	In the HTTP LB – Web Application Firewall section, only independent rules were supported, with no option to create shareable or reusable policies. Our goal was to enable users to access, modify, or disable existing WAF exclusion rules, switch to a shared policy when needed, and for LBs without existing rules, create new policies or reuse existing ones, as well as add or update rules within them.
	In the HTTP LB – Route – Security section, only inheriting rules from the parent LB was supported, with no option to select other rules. We aimed to allow users to either inherit existing rules or assign a specific policy (with rules) to the route when needed.
	In the Shared Objects section, there was no way to create or manage reusable policies. We aimed to let users create policies (with rules) once and reuse them across multiple HTTP LBs, eliminating repetitive configurations.
	In the Security Analytics dashboard – Events section, users reviewed events, identified false positives, and generated WAF exclusions through quick actions. Since the system only supported non-sharable rules, we aimed to retain existing rules while also enabling the creation of reusable policies.
	Users may also want to be notified of anomalous WAF behaviors (e.g., false positives). We could support this by providing notifications with links to supporting data and direct options to create policies (with rules) to mitigate the issue.
	For customers (esp. large ones) with existing inline rules per HTTP LB, we should support adding or migrating those rules into a new or existing policy, making previously non-sharable rules reusable across other LBs.

As we identified six main usage scenarios for WAF exclusions, I initially aimed to cover all. After aligning with PM and engineering, we decided to focus on the top four in this project since the last two required significant backend work and could be addressed in phase two. Phase one covered configurations in HTTP LB across four workspaces — Web App and API Protection (WAAP), Multi-Cloud App Connect (MCAC), Distributed Apps (DA), and Shared Configuration (SC) — with Content Delivery Network (CDN) LB expansion planned for phase two.

In conclusion, phase one of the WAF exclusion feature focused on four main entry points:

	In LB configuration (same as the rule configuration entry point)
	In route configuration within LB
	Event quick actions (same as the rule configuration entry point)
	Shared Objects section (policy could be configured independently and centrally managed)

Design Iteration & Improvement

Enhance efficiency and flexibility of WAF exclusion configuration.

Through design discussions and iterations, I helped PM think through how the system should interact with users — especially the rule auto-generation feature, which was unclear at the start. My questions clarified requirements and my proposals guided the solution, which PM later appreciated.

In the process, I aimed to simplify the hierarchy and layers of WAF exclusion creation in LB/route configuration, reduce user input workload for policy creation, and improve the feasibility and convenience of applying a policy.

Firstly, I aimed to simplify navigation and hierarchy. Initially, I considered placing the policy configuration entry alongside WAF exclusion selection, with options to create or connect to a policy in the next layer, and configuration details below — following the existing wizard pattern. However, feedback revealed no component supported dropdown selection in the second layer for object creation. I then tried presenting policy configuration in the same layer as WAF exclusion selection with a dropdown for new or existing policies, but this did not align with the design system. Ultimately, I refined the design to place policy configuration one layer below, while still letting users choose the configuration method using an existing component (oneof with dropdown selection) in the first layer, aiming to reduce hierarchy and save user time.

Improvement 2 - Efficient Policy Creation

Secondly, I worked to reduce user input workload for policy creation and improve the convenience of connecting to a policy. I began by exploring interaction designs for selecting a configuration method — disable, create new, or connect to existing. To give users more flexibility when creating new policies, I considered supporting both starting from scratch and cloning an existing one. In discussions with the design system team, we proposed populating content from an existing policy after choosing to create a new one, as it better aligned with user mental models. Later, I discovered that the Shared Objects section already supported cloning, so aligning with this existing functionality became the more consistent approach. Ultimately, I applied an existing design pattern to enable cloning and editing for policy configuration.

Thirdly, I clarified all scenarios for auto-generating rules from Security Analytics Dashboard events to ensure the design covered every use case. Users reviewed logs, identified issues, and created policies to mitigate them. Through multiple clarification sessions with PM, I broke down four key scenarios based on whether the tied LB had inline rules, was already connected to a policy, or had a route with a matching policy. With clear interaction flows, I effectively aligned stakeholders on the requirements.

Final Design

Demonstrate the user flow covered in phase one.

Below are prototypes illustrating the enhanced WAF exclusion experience — showing how the implementation evolved to support the new policy feature while preserving existing configured rules.

In the LB – WAF configuration, there was a WAF Exclusion section. If inline rules were configured, they would appear by default. Users could add or edit existing inline rules, switch to a policy, or disable the configuration entirely.

In the LB – WAF – WAF Exclusion section, if no inline rules were configured, the default setting was disabled. Users could enable a policy, at which point the required policy configuration field would appear. They could configure the policy by connecting to an existing one, cloning and editing an existing policy, or creating a new one from scratch. Within a policy, rules could be added or edited. If no policy configuration option was selected before proceeding, an error status would be displayed.

In the LB – Route – Security configuration, the WAF Exclusion section allowed users to either inherit the configuration from the LB or configure a custom policy by connecting to an existing one, cloning and modifying an existing policy, or creating a new one from scratch. Within a policy, rules could be added or edited.

In Shared Objects – WAF Exclusion Policies, users could add new policies as well as review and manage previously added ones. This included viewing rules, checking LBs/routes connection via local status, editing configurations, cloning policies, and deleting them.

In the Security Analytics – Events section, users could review event logs, identify issues, and take quick actions to mitigate risks — such as creating WAF exclusions. There were four main possible scenarios. In the demonstration, if a policy was already configured for the associated LB, users would be directed to the rule configuration section within the existing policy.

Reflection

Limitation

	Phase one only supported core HTTP LB use cases.
	Configuration navigation still had room for improvement.

Next Step

	Provide notifications with next-step actions and guidance for mitigating false positives.
	Support migration of existing inline rules into reusable policies.
	Show users which specific LBs/routes will be impacted by new configurations in the Shared Objects section.
	Allow editing of LB/route connections to policies directly within Shared Objects.
	Extend WAF exclusion policy support to Content Delivery Network (CDN) LBs.

What I Learned

Rather than jumping straight into design from PM requirements, stepping back to clarify use cases and user goals helps the team align on project objectives and ensures design efforts address real user needs.