What to know when buying a web application firewall

A web application firewall is one of the more complex security investments an organisation can make – not because the concept is difficult, but because the gap between deploying a WAF and having one that actually works is wider than most organisations anticipate. Default configurations provide baseline protection but rarely match the specific applications they are meant to defend. Without tuning, monitoring, and ongoing maintenance, a WAF can provide false confidence rather than genuine protection.

This guide covers how WAFs work, what to look for when evaluating options, and the mistakes that undermine most implementations.

What is a web application firewall?

A web application firewall monitors, filters, and blocks HTTP and HTTPS traffic to and from web applications. Where a traditional network firewall operates at the network layer, a WAF works at the application layer – giving it visibility into the actual content of web requests, not just their headers and routing information.

This distinction matters. Next-generation firewalls can inspect traffic using deep packet inspection and are designed for general network security. A WAF is a specialist tool, purpose-built to understand web application logic, parse HTTP requests in detail, and defend against attacks that exploit application-layer vulnerabilities.

How a WAF works

Modern WAFs use several detection methods, typically in combination.

• Signature-based detection compares incoming requests against a database of known attack patterns. This approach effectively blocks documented vulnerabilities and common attack techniques. Its limitation is that new, unknown attacks – zero-day exploits – will not match existing signatures until the database is updated.
• Behavioural analysis monitors traffic patterns and flags anomalies. If an application typically receives a certain volume of login attempts and suddenly sees a dramatic spike, behavioural analysis identifies this as suspicious even if each individual request appears legitimate. This method catches attacks that signature-based detection may miss.
• Positive security models define what legitimate traffic looks like and block everything else. Rather than identifying every possible attack, this approach specifies acceptable parameters, formats, and values for each application endpoint. Anything that does not conform is blocked. This is more restrictive but provides stronger protection against unknown threats.

Common threats a WAF protects against

• SQL injection attacks insert malicious database commands into input fields, exploiting applications that do not properly validate user input. A successful SQL injection can expose entire databases including customer records and credentials. WAFs identify SQL syntax in request parameters and block these attempts before they reach the application.
• Cross-site scripting (XSS) attacks inject malicious scripts into web pages viewed by other users. These can steal session cookies, redirect users to phishing sites, or modify page content. WAFs detect script tags and JavaScript code in unexpected locations within requests.
• Application-layer DDoS attacks flood applications with requests designed to consume server resources – complex database queries, resource-intensive page loads – rather than simply overwhelming bandwidth. WAFs identify and block these request patterns.
• Bot attacks use automated traffic to probe applications for vulnerabilities, scrape content, or stuff credentials. WAFs distinguish between legitimate users and automated traffic based on request patterns, timing, and behaviour.
• API abuse exploits the interfaces organisations expose for application integration. WAFs can enforce rate limits, validate request structures, and ensure API calls conform to expected patterns.

Key considerations when evaluating a WAF

Deployment model

WAFs can be deployed in three ways. Cloud-based WAFs route traffic through the provider’s infrastructure, offering rapid deployment, automatic updates, and scalability without hardware. They suit organisations with limited security staff or distributed cloud environments, though you are dependent on the provider’s infrastructure. On-premise WAFs run within your own data centre, giving complete control and keeping traffic within your environment – better for organisations with data sovereignty requirements, but at the cost of greater operational overhead. Hybrid approaches combine both, often using on-premise WAFs for data centre applications alongside cloud-based protection for public-facing services.

The right choice depends on where your applications run, how your traffic flows, and the level of control your compliance obligations require.

Scalability and performance

Your WAF needs to handle traffic spikes without becoming a bottleneck. Cloud-based WAFs typically scale automatically. On-premise solutions require capacity planning. Ask vendors about throughput capacity, latency impact, and performance during DDoS conditions. A WAF that cannot keep pace with legitimate traffic during peak periods will affect user experience.

Integration with existing infrastructure

A WAF operates within a broader security ecosystem and needs to work with it effectively.

SIEM integration allows your WAF to feed logs and alerts into your security information and event management platform. Ensure the WAF supports standard log formats and can stream events to your chosen SIEM.

Identity and access management integration enables the WAF to make decisions based on user identity rather than just IP addresses, supporting more granular policies.

DevOps and CI/CD pipeline integration matters if your development teams deploy frequently. WAF rules should be version-controlled and deployable alongside application code.

Network infrastructure compatibility is essential – verify the solution works with your existing load balancers, CDNs, and SSL/TLS configuration.

Automation and threat intelligence

Automated rule updates incorporate new threat intelligence without manual intervention. Machine learning capabilities identify emerging threats based on behavioural patterns. Comprehensive analytics provide visibility into attack trends and whether legitimate traffic is being affected. Real-time alerting with intelligent aggregation helps teams focus on genuine threats rather than noise.

Managed versus self-managed

A WAF is not a set-and-forget solution. Applications change, new vulnerabilities emerge, and attack techniques evolve. Consider the operational burden honestly.

Managed WAF services handle rule maintenance, tuning, and monitoring. This reduces overhead but may offer less flexibility. Self-managed solutions give complete control but require skilled staff to maintain and tune the WAF effectively. A misconfigured WAF can block legitimate traffic or leave security gaps.

Be realistic about your team’s capacity. A sophisticated WAF that sits misconfigured because no one has time to manage it provides less protection than a simpler, well-maintained solution.

Compliance and audit requirements

Regulated organisations need WAFs that support their specific compliance obligations. For NHS and healthcare organisations, this means demonstrating protection of patient data and meeting NHS England security standards. For public sector organisations working with sensitive data, audit trails need to satisfy the relevant regulatory framework. Look for WAFs that provide compliance-specific reporting and retain logs for the duration your obligations require.

Common pitfalls

• Over-reliance on default settings. WAFs ship with defaults designed to work across a range of applications. These provide baseline protection but rarely match specific applications precisely – they may block legitimate functionality or miss application-specific vulnerabilities. Tuning to your applications, analysing false positives, and creating custom rules for application-specific risks makes a material difference to protection quality.
• Lack of visibility. Some organisations deploy a WAF and assume they are protected without monitoring what it is doing. Problems surface only when users complain about blocked legitimate requests, or when a breach investigation reveals the WAF was not blocking attacks as expected. Dashboards showing WAF activity, regular review of blocked requests, and anomaly investigation are all necessary.
• Misalignment with business requirements. A WAF that provides excellent protection but creates unacceptable latency for customer-facing applications fails the business. A solution that requires constant manual intervention from a team without capacity creates risk. Start with your requirements – what applications need protection, what latency is acceptable, who will manage the solution, what compliance obligations apply – then evaluate options against these criteria.
• Treating a WAF as a complete solution. A WAF addresses application-layer threats but does not solve all security challenges. Application security requires a layered approach. Your WAF should complement network security, endpoint protection, and secure connectivity – not replace them.
• Failing to plan for hybrid environments. Most organisations run applications across data centres, cloud providers, and SaaS platforms. A WAF strategy that covers only on-premise applications leaves cloud workloads exposed. Plan for protection across the full application estate.

How Cloud Gateway delivers WAF

Cloud Gateway’s Secure Application Access delivers WAF capability as part of the managed platform, within the Protect pillar, alongside Managed Firewall, Secure Internet Access (SWG), and Secure Private Access (ZTNA). WAF capability integrates with the broader security and connectivity stack, with consistent policy applied across cloud, on-premise, and remote access scenarios under one operating model.

For regulated organisations, WAF logs and security events feed into the same visibility layer as network traffic and access records, supporting the continuous compliance evidence that DSPT, CAF, and PSN assessments expect. UK-based infrastructure and operations address data sovereignty requirements.

For more on how Secure Application Access works and how it fits within the platform, see our Secure Application Access page and our platform page.

Talk to an expert Secure Application Access