A web application firewall (WAF) inspects HTTP traffic to and from a website and applies rules to allow, challenge or block requests. It can reduce exposure to some common web attacks and abusive traffic. It cannot replace secure development, updates, access controls, backups or incident response.
Key takeaways
- Choose a WAF placement that fits the hosting and network architecture.
- Confirm whether the service is proxying traffic, monitoring it or only supplying rules.
- Test forms, logins, APIs, checkout and integrations to catch false positives.
- Keep the origin server protected and maintain separate application security controls.
- Assign an owner to review alerts, rules, exceptions and incidents.
How a WAF fits into the request path
A WAF applies security rules to web requests. Depending on the product, it may sit in a cloud proxy, at the hosting or network layer, or within the application. A cloud proxy can inspect requests before they reach the origin server, while a host or application WAF operates closer to the website. The placement affects what traffic it can inspect, how it handles encryption, what happens during an outage and who maintains it.
Some services offer managed rule sets for known attack patterns. Others let an administrator create custom rules for paths, request rates, countries or other signals. These controls can help filter traffic, but no ruleset identifies every malicious request or understands every business-specific workflow.
What a WAF can and cannot do
A WAF may block or challenge requests that match configured rules. It can also help limit some automated traffic and provide logs that support investigation. Its usefulness depends on placement, configuration, coverage and ongoing review.
A WAF does not fix vulnerable plugins, unsafe application code, weak passwords, exposed credentials or a compromised administrator account. It does not guarantee protection against denial-of-service attacks, data loss, fraud or downtime. Keep software updates, least-privilege access, multifactor authentication, backups and recovery procedures in place.
Choose a deployment that fits the site
Before enabling a WAF, map the path from visitor to application: DNS, CDN or proxy, load balancer, hosting, web server and application. Identify integrations that send traffic directly to the origin. If a proxy is used, discuss with the host how to prevent unfiltered direct access to the origin without blocking legitimate monitoring, mail or deployment services.
Check who terminates TLS, where logs are stored, which locations process traffic, how support handles incidents and what service limits or additional fees apply. Confirm whether the service is managed by the host, your team or another supplier. Record ownership of the account and billing relationship.
Configure and test carefully
Start in a monitoring or log-only mode if the service supports it. Review what would be blocked, tune rules for the actual site and then enable enforcement in stages. Test normal and unusual but legitimate journeys: contact forms, file uploads, account access, APIs, payment callbacks, search and integrations. Check both desktop and mobile behaviour.
A false positive can prevent a customer from completing a task. Keep a clear process to review a blocked request and add narrow exceptions where justified. Avoid broad allow rules that disable protection across an entire site. Keep a record of rule changes and a way to roll them back.
Operate the WAF over time
Assign someone to review security alerts and provider notices. Retest rules when the website, integrations or traffic patterns change. Confirm that logs are available for investigation and retained according to the organisation’s requirements. Include the WAF in incident response and recovery exercises.
For small organisations, a managed WAF from the hosting or network provider may be easier to operate than a separate platform. A larger or more complex site may need custom rules, dedicated monitoring and defined escalation. Compare the actual service and responsibility, not the label alone.
Frequently asked questions
Does a WAF make a website secure?
No single control makes a website secure. A WAF can be one layer, alongside updates, secure code, access control, monitoring and tested backups.
Can a WAF block every attack?
No. It applies rules to the traffic it can inspect, and rules can miss attacks or block legitimate requests. Keep other controls and an incident plan.
Should every WordPress site use a WAF?
The choice depends on business impact, hosting features, site complexity and who can operate the service. Check what protection is already included with the host before adding another layer.
For ongoing updates and recovery planning, see our website maintenance service.
Sources and review notes
Reviewed on 20 October 2026. WAF capabilities vary by provider and configuration. Review the provider’s current product documentation, logging and data-handling terms, service limits and incident process before deployment. Test the setup against the site’s real traffic and integrations.