DEV Community

Lia
Lia

Posted on

How to Reduce WAF False Positives Without Dropping Detection

#waf #falsepositives #detection #checklist

False positives are the cost a web application firewall pays when a real user request looks like an attack. Reducing that cost is not the same as turning protection off. It is a classification problem: identify what actually stopped the visitor, read the evidence the console already keeps, and compare detection postures only where the published numbers support a comparison. SafeLine is documented as a self-hosted web application firewall that filters and monitors HTTP and HTTPS traffic in front of an application, acting as a reverse proxy so clients reach the origin only after that filtering (SafeLine overview).

Start from the published detection tradeoff

The overview page publishes an effect evaluation on 33,669 samples. SafeLine Balance is listed at 71.65% detection, 0.07% false positives, and 99.45% accuracy. SafeLine Strict is listed at 76.17% detection, 0.22% false positives, and 99.38% accuracy. The same table lists ModSecurity Level 1 at 69.74% detection and 17.58% false positives, and CloudFlare Free at 10.70% detection and 0.07% false positives (SafeLine overview).

Those rows are the quantitative false-positive facts in the supplied documents. They do not describe your routes, your parameters, or a menu path for changing posture. Use them as a decision frame, not as a forecast. Among the two SafeLine rows, Balance is the lower false-positive result and also the lower detection result. Strict is the higher detection result and also the higher false-positive result. Accuracy stays high in both rows. If customers report unexpected blocks, the Balance figures are the published comparison that favors fewer false positives. If the report is a missed exploit, the Strict figures are the published comparison that raises detection and accepts a higher false-positive rate. Neither row is a promise for a checkout form or an admin search box.

Do not invent a third mode, a sensitivity number, or a threshold these pages do not publish.

Separate attack blocks from other documented controls

Documented core capabilities are defenses for web attacks, proactive bot-abuse defense, HTML and JavaScript code encryption, IP-based rate limiting, and a web access control list (SafeLine overview). The feature list also describes rate limiting, a captcha challenge, an authentication challenge, and dynamic protection.

Rate limiting throttles traffic that exceeds defined limits, including denial-of-service patterns, bruteforce attempts, traffic surges, and other abuse. A captcha challenge is documented to allow human users and to block crawlers and bots. An authentication challenge blocks visitors who do not enter the password. Dynamic protection encrypts HTML and JavaScript on each visit (SafeLine overview).

A ticket that says the firewall blocked a user may be any of those behaviors. An injection-style blocking page, a captcha, a password gate, and a throttle are not one failure. Ask for the URL, method, time, and what the visitor saw. If they saw a challenge or a password prompt, review that documented control. If they saw a blocking page after a request that looks like an exploit, review the attack record. The supplied pages do not publish default rate-limit values or captcha tuning steps, so this checklist does not invent them.

Named attack coverage includes SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, bruteforce, HTTP flood, and bot abuse (SafeLine overview). A normal search string can resemble SQL or a file path. That resemblance is why you review the request. It is not, by itself, proof that the control is wrong.

Review the attack list, then re-test known samples

After you proxy an application, the configuration guide says to check the web console attack list and to open detail for a specific event (Protect an application). That is the inspection path these sources describe. They do not describe a separate false-positive workbench.

For each complained request, record four facts. Note whether an attack record exists and what detail shows. Note whether the query, body, or path resembles a documented test case. Decide whether the same bytes would be dangerous from an untrusted client. Note whether the field is ordinary application input that often contains quotes, angle brackets, or dot-dot path text.

The same guide publishes samples to send against your own protected domain. SQL injection uses a union-select query string. XSS uses an image tag with an error handler. Path traversal requests a walk toward /etc/passwd. Code injection uses a phpinfo call and a system command. XXE uses a doctype with an external entity. A protected site is expected to show a blocking page, after which you confirm the event in the console (Protect an application). Replace the documentation example domain with your own domain. Do not send those probes to a site you do not operate.

Run the samples before and after any posture change. A change that quiets customer complaints but lets a union-select sample through has not reduced false positives. It has reduced detection. The evaluation table is useful only if the attacks you care about still produce a blocking page and an attack record on your hostname.

Rule out proxy mistakes before you relabel them

SafeLine is documented as an HTTP and HTTPS reverse proxy developed on nginx. It receives traffic for the original site, cleans malicious traffic, and forwards the remaining traffic to the upstream (Protect an application). An application entry needs a domain, hostname, or IP, a listen port such as 80 or 443, the SSL option for HTTPS, and the real upstream address. The domain must resolve to the SafeLine server.

If that path is wrong, users fail for reasons that are not false positives. Confirm that the name points at SafeLine, the listen port matches the application entry, HTTPS has SSL selected, and the upstream is the origin you intend. A failure from a dead upstream, a certificate warning, or a request that never reached the proxy should be closed as a routing defect.

Use a short weekly checklist

Keep the review small enough to finish.

  1. Group complaints by application, path, and symptom: blocking page, captcha, password prompt, or throttle.
  2. Match blocking-page reports to the attack list and open detail.
  3. Mark each event as likely malicious, likely legitimate, or not an attack detection.
  4. If legitimate requests dominate attack records, compare that pattern with the published Balance false-positive figure. Do not treat the figure as a guarantee.
  5. If missed exploits dominate, compare that pattern with the published Strict detection figure, and expect the documented false-positive rate to be higher.
  6. Send the five documented attack samples to your domain again and confirm both the blocking page and the attack record.
  7. Note fields that routinely contain attack-like text so the next review does not start from zero.

Stop there. The supplied overview, deploy guide, and application guide do not specify custom exception syntax, a per-parameter allow list, or an automatic false-positive tuner. If you need a control those pages do not describe, confirm it in the current product documentation or through the documented community channels, which include Discord and GitHub issues (SafeLine overview). Do not assume a hidden switch.

What counts as a WAF false positive?

A false positive is a legitimate request treated as malicious. In the published evaluation, false positives are counted separately from detection. A visitor stopped by an authentication challenge, a captcha, or rate limiting may be inconvenienced, but that event is a different documented control until an attack record exists for the request.

Does a lower false-positive rate mean attacks are ignored?

No. The table lists Balance at 71.65% detection and 0.07% false positives, and Strict at 76.17% detection and 0.22% false positives, on the same 33,669 samples, with accuracy of 99.45% and 99.38% (SafeLine overview). The lower false-positive row still reports substantial detection. Re-test the attacks that matter on your application instead of treating either percentage as a site-specific promise.

How should a blocked request be reviewed?

Open the web console attack list and click detail, which is the inspection step in the application guide (Protect an application). Compare the recorded request with the documented SQL injection, XSS, path traversal, code injection, and XXE samples. If there is no attack record, check rate limiting, captcha, the authentication challenge, and the reverse-proxy settings before you change detection posture.

Should rate limits be removed to reduce false blocks?

No. Rate limiting is documented as a throttle for traffic that exceeds defined limits, including bruteforce and surges, not as an exception list for attack signatures (SafeLine overview). Review it when the symptom is throttling. These pages do not publish default limit values, so do not copy a number from an unrelated guide.

What should stay out of a false-positive change?

Do not add undocumented rule text, disable attack defense to silence one form, or skip the sample re-test. A useful change is one you can explain from the attack detail, the published Balance versus Strict comparison, and a fresh block of the documented attack samples on your domain.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

Top comments (0)