A business needs a web application firewall (WAF) when it runs a public web application that handles logins, payments or customer data, and cannot patch or monitor it fast enough. A WAF filters web attacks at the HTTP layer. It is a useful extra layer, not a fix for insecure code.
What problem does a WAF solve for a smaller company?
OWASP describes a WAF as an application firewall for HTTP applications that applies rules to an HTTP conversation, aimed at common attacks like cross-site scripting and SQL injection. It sits in front of specific web applications and can be viewed as a reverse proxy.
For a small team, two situations make that valuable. The first is a gap between a vulnerability becoming known and your patch going live: a rule can block the attack pattern meanwhile. The second is background noise: bots probing login pages and common paths all day. A WAF absorbs a lot of that before it reaches your code.
Where do the rules come from?
Most teams do not write rules from scratch. The OWASP Core Rule Set (CRS) is described by its project as a set of generic attack detection rules for use with ModSecurity or compatible web application firewalls, aiming to protect web applications from a wide range of attacks, including the OWASP Top Ten, with a minimum of false alerts. Its listed categories include SQL injection, cross-site scripting, local and remote file inclusion, code injection, shell injection, session fixation and scanner or bot detection.
When we read the project page on 18 October 2026, it listed release 4.30.0 as the latest and 4.25.2 as a long-term support release, noted that 3.3.x is end of life, and described fixes for bypass issues in the 4.25.2 notes. The practical lesson is that rule sets themselves have bugs and bypasses, and need updating like any software.
What will it not do?
A WAF does not know your business rules. It cannot tell that a customer should not see another customer's invoice, or that a discount code can be reused. Those flaws look like ordinary requests.
It also does not help if attackers can reach your application server directly, around the WAF. And it adds work: OWASP notes a WAF often requires customization that has to be maintained as the application changes.
How does a business decide?
A constructed example. A twelve-person company runs an online booking site for a clinic network. It has a customer login, stores names and appointment times, and has one part-time developer.
The questions it should ask: What happens if the site is down for a day? Is personal data stored? How quickly can the developer ship a fix? Does a contract or customer questionnaire ask about web protections? If the answers are "bookings stop," "yes," "a week," and "yes," a WAF in front of the site earns its place. If the site is a static brochure page with no forms, the same money is better spent on updates, backups and two-factor login for the admin account.
How to check or apply this
- Write down which of your web applications are public, and what data and logins each holds.
- Confirm the basics first: updates applied, admin access protected with multi-factor authentication, backups tested.
- Pick a WAF delivery model you can operate. A managed service in front of the site is easier for small teams than running your own appliance.
- Start in detection-only mode and review what would have been blocked for a week or two.
- Turn on blocking for high-confidence rule groups first, and keep a quick way to disable a rule that breaks a page.
- Make sure the application server only accepts traffic that comes through the WAF.
- Schedule rule updates, and keep a list of application bugs the WAF is currently covering for, each with a ticket.
Quick check
Is a WAF enough to secure a web application?
No. It filters known attack patterns at the HTTP layer. Authorization flaws and business logic bugs need fixes in the application itself.
Should a new WAF block traffic on day one?
Usually not. Run it in detection-only mode first, review false positives, then enable blocking in stages so you do not stop real customers.
Sources
Last reviewed: 18 October 2026.
