Introduction
It’s more important than ever to defend websites and web applications from attacks. Each month brings fresh headlines of organizations suffering cyberattacks ranging from the embarrassing to the catastrophic. In April 2025, an attack against British retailer Marks & Spencer resulted in an estimated $400 million in lost revenue.
What’s the most efficient way to manage risks from these persistent threats?
The best defensive approach for websites and web apps is to use multiple, independent layers of defense. This can be pictured like the layers of an onion, with the secured application sitting at the centre. If an attack bypasses a layer of defense, then additional defensive layers are still actively providing security.
Adding a WAF: The Good and the Bad
The Benefits
A web application firewall (WAF) is one important example of a layer of defense. A WAF monitors the flow of web traffic, detects traffic that looks malicious and proactively blocks it. This helps prevent public-facing websites and apps from being low-hanging fruit for attackers. Any web service on the public internet should implement a WAF. Many security standards (such as PCI DSS) and organizations have robust security policies that mandate the defense of a WAF.
The Drawbacks
If the security benefits of deploying a WAF are so great, what’s the catch?
Adding the security rules and checks that a WAF provides can cause false positives: errors that interfere with the normal operation of the web service sitting behind the WAF. These errors have the potential to bring misery to both users and the engineers tasked with an endless game of Whack-A-Mole to fix them.
This blog post is the first in a series exploring WAF features. It discusses the problem of false positives when using a WAF and explores how to easily mitigate false positives using the enhanced WAF features in Progress LoadMaster 360. The topics covered include:
- What is a false positive?
- Why are false positives a problem?
- How can we fix false positives, and how do LoadMaster 360 enhanced tools help?
What Is a False Positive?
When using a WAF, like the one built into Progress Kemp LoadMaster, the basic flow of operation is the same. For each HTTP web request received from a user, a series of rules are executed on each request. These “WAF rules” are each designed to detect a different malicious or anomalous behavior.
Examples of WAF rules include:
- Is the request missing its host header? (A standard part of a web request)
- Is the request trying to access a suspicious file type? (E.g. .bat, .conf, .ini)
- Does the request contain SQL commands? (Possible injection attack)
A legitimate HTTP request should pass through the WAF’s set of detection rules and be considered benign. The WAF should accept the legitimate request and allow it to continue its journey to the application server, like so:
| Did you know? A competent WAF—including the LoadMaster WAF—should also feature the ability to process and inspect HTTP responses. This makes it possible to check for sensitive information leakage, for example. Response inspection is far less common than request inspection, however. To keep things simple, this post will focus only on requests. |
What happens when a legitimate request causes a WAF detection rule to match? This is considered an error and is referred to as a false positive. The mistaken rule causes the legitimate request to be treated as potentially malicious, and the WAF could deny the request:
Why Are False Positives a Problem?
Poor User Experience
The most immediate problem caused by false positives is a poor user experience. Imagine pressing the “Submit Order” button on a webstore only to be greeted with a “403 Access Denied” error and a dead end. The result is an infuriating annoyance. When false positives lead to blocked requests, they stand in the way of genuine users doing what they need to do.
Upset users might complain, creating the knock-on effect of pressure from stakeholders to disable or even remove the WAF to fix the underlying problem. Such a step would be a significant sacrifice of security in the interest of usability.
Alert Fatigue
If a WAF generates many false positives, then the real attacks are easily lost in the noise. Crucial security intelligence can be lost this way. Moreover, operations and security teams will naturally pay less attention to the alerts from a WAF if it has a reputation for constantly raising false alarms: this, again, leads to real attacks being overlooked.
Compliance (Sensitive Information)
The cause of a false positive is often user-submitted data, for example, usernames, passwords, shipping addresses, etc. When a WAF rule matches in error against such user input, the offending data is written to the WAF’s log file, which means an offending password, address or other information is logged in plain text. This can violate data protection regulations like GDPR, CCPA, PCI DSS and others, so false positives must be remedied to help prevent this.
An example of personal information causing a false positive and being logged:
How Can We Fix False Positives?
‘Turn Down the Volume’: Can We Ignore False Positives?
To be as simple and as frictionless as possible, some commercial WAF vendors approach the problem of false positives by mostly ignoring them. This typically takes the form of underreporting (hiding rule matches unless they cause a full blocking event) and setting the WAF to a low sensitivity level (requiring a request to trigger many rules before blocking it).
This type of approach can create a “set it and forget it” style WAF solution, which is quiet and causes minimal fuss. While this may sound ideal, the main problem is that the low sensitivity makes the WAF much easier to evade and likely doesn’t provide the level of security expected. With lower sensitivity, an attack must now be more extreme for it to stand out and be detected. Also, hiding false positives makes them difficult (if not impossible) to properly investigate and resolve.
Tune Out the Noise: Fully Resolving False Positives
The best and most secure approach is to “tune away” false positives when they’re encountered. When a detection rule matches in error and a false positive occurs, then this should be investigated.
For example, is the offending rule that’s causing a false positive irrelevant to the web application being defended (e.g., a PHP injection rule, but PHP isn’t in use anywhere)? If so, the rule can be disabled, and the noise, or false positives, it causes will immediately disappear.
Is the offending rule only causing problems for a specific part of the web application, but it’s working fine everywhere else? The rule can be tuned by disabling it for the problem-causing location—e.g., /webstore/quote-form—and the false positives will disappear.
Is a specific piece of user input regularly causing false positives with certain rules? For example, a free text box where users can write and submit a delivery note. The false positives can be tuned away by excluding the free text box from the rules that cause problems (or even excluding it from all detection rules if it causes significant issues across the board).
By working methodically and tuning away the noisy false positives, what remains are the attacks that become plain to see and easy to block on a well-tuned WAF.
Fixing False Positives: The Traditional Approach
The process of tuning WAF rules to resolve false positives involves reviewing log files, finding the false positives and resolving them. A typical strategy is to start by solving the most egregious false positives first: find them, resolve them fully and then repeat the process.
In an ideal world, this initial tuning process would occur in an isolated test environment to remove the possibility of mistaking a real attack for a false positive. Time and resources often don’t allow for this, however, and working with real traffic from day zero is often unavoidable.
Identifying a genuine false positive requires a level of experience. Some useful markers include:
- The rule being triggered (does it cause false positives often or rarely?)
- The source IP address (is it an expected address? Where is it located?)
- The resource being accessed (does it look like a legitimate location or is it bogus?)
- The time of day (a business application accessed during office hours versus at 4 a.m.)
Once identified, the false positive is resolved by writing either a new directive or a new rule to tune the offending rule by adjusting its behavior. This is ideally done conservatively to allow the blocked legitimate traffic to pass, without opening a hole in the WAF that could allow attacks to start passing through undetected.
Turbo-Charged False Positive Tooling in LoadMaster 360
The LoadMaster 360 platform features a bespoke suite of enhanced WAF reporting and tooling. This is specifically designed to make the process of identifying and resolving WAF false positives faster and easier.
Time-Saving Smart Filters
To aid at the beginning of the false positive tuning process, the WAF log data is pre-filtered through a series of smart filters to automate as much of the heavy lifting as possible. The vast majority of WAF events are filtered away, leaving only the most likely false positive candidates for the attention of a human operator.
Consider this example:
The idea of manually reviewing and making judgment calls on 1584 WAF events seems impossible. But, after applying LoadMaster 360 smart filters, just 13 possible false positives were highlighted for human review. 13 is a more manageable starting point than 1,584 (or even the full 83,000+).
Automatic Rule Tuner
LoadMaster 360 WAF simplifies tuning by automatically generating the correct instructions when a false positive is found. This automation removes the need for technical knowledge, making WAF configuration accessible to non-experts.
The automatic rule tuner contains a range of options and functionality. It deserves further exploration. Some onboarding knowledge is required to use it effectively. Common questions that arise include:
- How is the rule tuner used?
- What are the best and most secure options to use?
- When is it appropriate to use one “rule exclusion type” over another, and what do they mean?
A follow-up series of blog posts will explore the rule tuner in detail, how to use it and its various options, and will walk through a series of examples from start to finish.
Get Started with LoadMaster WAF and LoadMaster 360 Today
Is your load balancer handling public web traffic? If so, you may want to explore LoadMaster WAF capabilities to strengthen your web application security posture.
Do you already have a LoadMaster Enterprise Plus subscription? If so, you already have full access to LoadMaster WAF capabilities.
Are you using LoadMaster 360, and have you tried its enhanced WAF features? If not, this is the perfect time to get started. Follow along with the WAF tutorials in the rest of this series and start getting to grips with LoadMaster 360 WAF-enhanced functionality. Gaining the security benefits of a well-tuned WAF solution is within reach!
