Web Application Firewalls (WAF): Protecting Your Online Presence

A Web Application Firewall (WAF) is a security control that monitors, filters, and blocks HTTP/HTTPS traffic to and from a web application. Unlike a traditional network firewall that operates at Layer 3/4 (IP addresses and ports), a WAF operates at Layer 7 (the application layer), inspecting the content of each HTTP request and response. This allows it to detect attacks that are invisible to network firewalls — such as SQL injection payloads embedded in form fields, cross-site scripting (XSS) attempts in URL parameters, or file inclusion attacks targeting server-side scripts.

WAFs can operate in several modes. In reverse proxy mode, the WAF sits in front of the web server and all client traffic passes through it — the most common deployment model for cloud WAFs. In transparent bridge mode, the WAF is inserted inline on the network without requiring IP address changes. In agent mode, a software module runs on the web server itself (such as ModSecurity for Apache/Nginx). Each mode has trade-offs in terms of performance, visibility, and deployment complexity, but reverse proxy mode is by far the most widely adopted because it provides full request and response inspection with minimal changes to existing infrastructure.

The Open Web Application Security Project (OWASP) publishes the OWASP Top 10, a periodically updated list of the most critical web application security risks. The current list includes Broken Access Control, Cryptographic Failures, Injection (including SQL injection), Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Monitoring Failures, and Server-Side Request Forgery (SSRF). A well-configured WAF can mitigate many of these risks at the network perimeter before malicious requests ever reach the application code.

It is important to understand that a WAF is not a substitute for secure coding practices. The WAF provides a critical layer of defence-in-depth, but the application itself must be designed and coded securely. WAFs are most effective as a shield that buys time — protecting against known attack patterns and zero-day exploits while developers work on patching the underlying vulnerability. This is sometimes called virtual patching: deploying a WAF rule that blocks exploitation of a specific vulnerability until the application code can be updated.

Cloud WAFs are delivered as a service, typically by routing DNS to the WAF provider's network, which then proxies clean traffic to the origin server. This model requires no hardware or software installation, scales elastically to handle traffic spikes and DDoS attacks, and is managed through a web-based console. Cloud WAFs are ideal for organisations hosting web applications in public cloud environments or using SaaS platforms, and they often bundle CDN and DDoS mitigation capabilities. Leading cloud WAF providers include Cloudflare, AWS WAF, Azure Front Door with WAF, Akamai, and Fastly.

On-premises WAFs are deployed as physical or virtual appliances within the organisation's data centre, sitting in front of locally hosted web servers. Vendors such as Fortinet (FortiWeb), F5 (BIG-IP ASM / Advanced WAF), and Barracuda offer on-premises WAF appliances. This model provides full control over the inspection pipeline, avoids routing traffic through a third party, and may offer lower latency for applications served from the same data centre. However, on-premises WAFs require the organisation to manage hardware lifecycle, software updates, rule tuning, and capacity planning — and they do not inherently provide DDoS protection at the network edge.

In reverse proxy mode, the WAF intercepts all inbound HTTP/HTTPS requests before they reach the origin web server. The client connects to the WAF's IP address (published via DNS), and the WAF terminates the TLS connection, inspects the decrypted request against its rule set, and then — if the request is deemed safe — re-encrypts and forwards it to the origin server. Responses from the server follow the same path in reverse, allowing the WAF to inspect outbound data for information leakage (such as stack traces, database error messages, or credit card numbers appearing in responses).

Reverse proxy mode provides the deepest inspection capability because the WAF has access to the full HTTP transaction — headers, cookies, request body, response body, and status codes. It also allows the WAF to add security headers (such as Content-Security-Policy, X-Frame-Options, and Strict-Transport-Security) to responses, enforce rate limiting per IP or session, and implement bot detection using JavaScript challenges or CAPTCHA. The trade-off is that the WAF becomes a single point of failure for web traffic, so high availability and performance are essential considerations when selecting a provider.

Deploying a WAF with out-of-the-box rules is only the beginning. Every web application is different, and generic rules will inevitably produce false positives — legitimate requests that are incorrectly blocked. A content management system that accepts HTML input in form fields, an API that receives JSON payloads with special characters, or a file upload endpoint that handles binary data can all trigger default WAF rules designed to block injection attacks. If false positives are not addressed, business stakeholders will push to disable the WAF entirely — defeating its purpose.

Best practice is to deploy the WAF in detection mode (also called learning or monitoring mode) for an initial period, logging all rule triggers without blocking traffic. During this phase, review the logs to identify false positives and create targeted exceptions — for example, excluding a specific URL path from SQL injection inspection because it legitimately contains query syntax. Once the false positive rate is acceptable, switch to prevention mode where matched rules actively block requests. Ongoing tuning is required as the application evolves — new features, API endpoints, and third-party integrations may require new exceptions.

Cloudflare WAF is one of the most widely deployed cloud WAFs globally, popular for its ease of setup, comprehensive free tier for basic protection, and extensive global network with a point of presence in Sydney. Cloudflare combines WAF with CDN, DDoS mitigation, bot management, and zero trust network access in a single platform. For resellers, Cloudflare offers a partner program that allows white-label management of client zones, making it straightforward to offer WAF-as-a-service.

AWS WAF is tightly integrated with the AWS ecosystem, attaching directly to Application Load Balancers, CloudFront distributions, and API Gateway endpoints. It uses a rules-based model where customers can write custom rules or subscribe to AWS Managed Rules, and is billed per rule and per million requests inspected — making it cost-effective for applications already running on AWS. Fortinet FortiWeb is a strong choice for organisations using the Fortinet Security Fabric ecosystem, offering both appliance and cloud deployment options with machine learning-based anomaly detection that reduces false positives. FortiWeb integrates with FortiSandbox for advanced threat analysis and provides a familiar management experience for teams already skilled in Fortinet products.

As organisations increasingly expose functionality through REST and GraphQL APIs, WAF vendors have expanded their capabilities to protect API endpoints alongside traditional web pages. API-specific WAF features include schema validation (ensuring that API requests conform to the expected OpenAPI or JSON Schema definition), rate limiting per API key or token, detection of abnormal parameter patterns, and blocking of common API attack techniques such as Broken Object Level Authorization (BOLA). For resellers advising clients who are building or consuming APIs, ensure the chosen WAF solution includes API-aware inspection rather than treating API traffic the same as traditional web page requests.