A web application firewall (WAF) is a filter that sits in front of a website or web app, inspects each incoming web request and blocks or flags requests that look like attacks before they reach the application. For an online shop, booking system or customer portal, it adds a layer against common web attacks, alongside good code, updates and monitoring rather than in place of them.
What a WAF does
Every time someone loads a page, submits a form or calls an API, their browser or app sends an HTTP request. A WAF reads these requests, including the address, headers, cookies and form fields, and compares them with a set of rules. For each request it can:
- allow it through to the website as normal
- block it and return an error page
- challenge it, for example with a check that the visitor is a real browser
- log it for review without blocking
Rules usually come from two places: managed rule sets maintained by the WAF provider for widely known attack types, and custom rules your team adds for your own site, such as limiting how often one address can try to log in.
WAF vs network firewall
A traditional network firewall decides which connections are allowed based on things like IP address and port. It does not usually look inside the web request to judge whether a form submission is an attack.
A WAF works at the application layer. It assumes the web traffic is allowed in, then checks what each request is trying to do. Most businesses need both: the network firewall limits which services are reachable, and the WAF watches the traffic to the services that must stay public.
What a WAF can help with
- Common injection attacks, such as SQL injection and cross-site scripting attempts hidden in form fields or URLs.
- Known vulnerabilities: when a flaw in widely used software becomes public, WAF providers often add rules that block known exploit attempts. This is sometimes called virtual patching. It can reduce risk while you update, but it does not replace the update itself. Our PHP2Shell article is one recent case where a provider added rules and still advised customers to patch.
- Automated abuse, such as bots repeatedly trying passwords, scraping pages or submitting spam forms, through rate limits and bot checks.
What a WAF cannot do
- Fix flaws in your own code. If a logged-in customer can view another customer's orders by changing a number in the address, the request looks normal and a WAF will usually let it through.
- Stop logins with stolen passwords that look like ordinary sign-ins. Multi-factor authentication is the better control here.
- Protect a server that can be reached directly. If attackers can find the origin server's address and bypass the WAF, the rules do not apply.
- Work perfectly without tuning. Strict rules can block real customers (false positives), while loose rules let attacks through.
Ways a WAF is deployed
- Cloud or edge WAF: traffic passes through the provider's network before reaching your server. This is often bundled with a content delivery network (CDN), and usually involves a DNS change.
- Cloud platform WAF: attached to the load balancer or gateway of your cloud hosting.
- Server or application level: a module on the web server or a security plug-in inside the CMS. These are easy to add but run on the same server they protect.
Which fits depends on your hosting, budget and who will manage it. Your host or developer can explain what is already available.
Setting one up sensibly
- Start in log or monitor mode, review what would be blocked, then switch rules to blocking.
- Test checkout, login, forms and API calls after enabling rules, ideally on a staging environment first.
- Lock down the origin server so it only accepts traffic from the WAF, where the setup allows it.
- Keep software and plug-ins updated. The WAF buys time; it does not remove the vulnerability.
- Send important WAF alerts into your website monitoring routine and agree who reviews them.
- Include the WAF in the scope of a penetration test so you know what it does and does not catch.
Questions to ask your developer or host
- Is there a WAF in front of our website, and is it blocking or only logging?
- Which rule sets are switched on, and who updates them?
- Who handles false positives if customers are blocked?
- Can the origin server be reached without going through the WAF?
- Is WAF review part of our support arrangement?
To review WAF, hosting and access controls together, see technine.io's cybersecurity and compliance service.
Frequently asked questions
Does a small business website need a WAF?
Any public site with logins, payments or forms can be hit by automated attacks, whatever its size. Many hosting and CDN plans include basic WAF features, so check what you already have first.
Will a WAF slow down my website?
Inspection adds some processing, but with a well-configured WAF the effect is usually small. Measure page speed before and after rather than assuming.
If I have a WAF, do I still need updates and testing?
Yes. A WAF reduces exposure to known attack patterns. Updates fix the underlying flaws, and testing finds problems that no generic rule can recognise.