How to tackle false positives in web application security

What is a false positive in cybersecurity?

A false positive is like a false alarm when your house alarm is triggered, but there is no burglar. In web application security, a false positive is when a web application security scanner indicates that your website has a vulnerability, such as SQL injection or cross-site scripting (XSS), but in reality, there is nothing there to fix. In other areas of cybersecurity, false positives can be literal false alarms that security professionals chase endlessly, looking for non-existent cyberattacks.

No wonder false positives are a leading cause of burnout among security professionals.

False negatives in web application security are vulnerabilities that exist but were not found by a vulnerability scanner. Because you need to know about the security vulnerability in advance, the concept of false negatives only makes sense in artificial test environments for benchmarking or evaluation – see our blog post on false negatives to learn more.

False positives make web application security unaffordable

All AppSec work needs a good vulnerability scanner, whether as a standalone tool for dynamic application security testing (DAST) or as an aid to manual penetration testing. In both cases, having a large number of false positives makes securing your web assets time-consuming and expensive.

It is AppSec best practice to build security testing automation into your web development pipeline and test as early as possible. To keep up with software innovation, you need to automatically feed vulnerability scan results into the dev workflow – but this won’t work if they include false positives. If your teams cannot trust the scanner, your security experts will have to manually validate each scan result, wasting time and money and holding back the entire development process. In a typical enterprise environment, that gets costly fast – to the tune of $500K a year.

In penetration testing, false positives are no less harmful. When flooded with false positives from a low-quality scanner, security experts will spend valuable time investigating non-issues instead of focusing on vulnerabilities that really need their expertise. This can make security testing seem too costly for some organizations, resulting in incomplete security coverage that puts them at risk of cyberattacks – but it gets worse.

False positives obscure real web application vulnerabilities

Humans tend to start ignoring false alarms rather quickly, and AppSec professionals are no exception. If a web application security scanner detects 200 cross-site scripting vulnerabilities and a security engineer or penetration tester finds that the first 20 variants are false positives, they will likely assume that all the XSS reports are false positives and ignore them.

False positives cause users to distrust all scan results by default and treat common issues like noise. This creates a major security risk, as real vulnerabilities may slip through testing undetected and leave the door open for malicious hackers. And because they’ve been manually flagged as false positives, they could remain unfixed and unreported for a long time, creating an even greater security threat.

Investigating a false positive takes skill and time

Whenever a security engineer, penetration tester, or application developer needs to investigate a false positive scan result, the effect is only as good as that person’s skill, experience, and perseverance. If users cannot rely on their scan results, they will naturally assume that whatever they can’t find or prove manually must be a false positive.

In reality, cutting-edge vulnerability scanners incorporate many years of AppSec research and development, so they can (and do) report vulnerabilities that a specific user might miss or be unable to verify. If such advanced vulnerabilities are dismissed out of hand as false positives, they may never be fixed – once again leaving the web app at risk of attack.

Trusting your AppSec solution becomes even more critical with non-interactive web assets such as APIs, where investigating a vulnerability report often requires dedicated tools and skills. False positives in API scan results can be a real deal-breaker, forcing developers to waste precious time checking their source code for non-existent defects. When release deadlines loom, many dev teams will be tempted to skip these troublesome security checks – and research confirms that up to 70% of them do exactly that.

The hidden costs of false positives in modern AppSec

Any serious web application security program needs a vulnerability scanner. No matter where and how you use it, the accuracy and real-life effectiveness of your chosen solution can make or break your AppSec efforts, so this decision needs far more care than just ticking a box. Whether you rely on web vulnerability scanning for all your dynamic security testing or combine it with manual penetration testing, inaccurate results riddled with false positives can jeopardize the hard work of your teams, impact your security posture, and actually cost you money.

A high-quality DAST solution integrated into your software development workflow, especially in modern DevSecOps shops, can serve as a standalone tool for finding real issues and tracking their remediation with very little hands-on interaction. An inadequate scanner, on the other hand, will always require your security engineers to spend precious time manually verifying scan results, providing developers with remediation guidance, and retesting fixes. Add to this the developer time wasted on investigating false alarms and getting actionable information from the security team, and you are paying for hundreds of hours a year devoted to the manual validation of low-quality vulnerability reports.

Automated scanners will never replace professional penetration testers, and a robust AppSec program should combine both. However, a good tool can make manual testing quicker and more cost-effective, allowing testers to focus on vulnerabilities that can’t be detected automatically – while a bad tool will make the whole process slower and more expensive. Similarly, if you run a bug bounty program, an accurate vulnerability scanner will let you identify and fix the majority of common security defects in-house without paying out bounties for trivial bugs. As the ethical hackers then focus on more advanced attack avenues, you get far better value for money – and better protection from real threats.

Demonstrably accurate: Invicti’s Proof-Based Scanning

Practically every vendor of application security testing tools will claim “fewer false positives” or even “zero false positives,” but any discussion about the number of false positives is really answering the wrong question. Even having zero false positives is no good on its own – you could get zero false positives simply because the scanner skipped anything it was unsure of. So a better question is: Can the solution find real, exploitable vulnerabilities and deliver true positive results for your developers to fix? Invicti’s Proof-Based Scanning technology was designed to provide the answer.

The only way to show that a vulnerability is exploitable is to actually exploit it and then demonstrate how it was done. Invicti builds on well over a decade of web security research and development to deliver a web application security solution that can find, safely exploit, and confidently confirm the vast majority of direct-impact vulnerabilities – over 94% of them, to be exact. By providing clear proof of exploitation for the security defects that really matter, Invicti side-steps futile arguments about who has fewer false positives and focuses squarely on making your web applications more secure.

Read our full white paper: False Positives in Web Application Security – Facing the Challenge