DEV Community

禾
禾

Posted on

How to Reduce WAF False Positives Without Guessing

#waf #falsepositives #detection #checklist

A blocked checkout is not automatically a bad signature. Sometimes the request never reached the origin because the proxy record is wrong. Sometimes a rate limit, a CAPTCHA, or a password challenge did exactly what the configuration says. Calling every one of those events a false positive is how teams disable attack detection and then call the outage fixed.

SafeLine's public docs do not give you a false-positive exception file, a per-parameter ignore list, or a command that tunes a threshold. They do give you a published evaluation, a reverse-proxy setup, and a short list of controls that block or reshape traffic on purpose. A reduction plan has to stay inside that boundary. Anything else is an unsupported integration.

Start from the evaluation table, not from a ticket title

The documentation home page publishes one effect evaluation. Total samples are 33669 in every column. SafeLine Balance is listed at 71.65% detection, 0.07% false positive, and 99.45% accuracy. SafeLine Strict is listed at 76.17% detection, 0.22% false positive, and 99.38% accuracy. The same table lists ModSecurity Level 1 at 69.74% detection, 17.58% false positive, and 82.20% accuracy, and CloudFlare Free at 10.70% detection, 0.07% false positive, and 98.40% accuracy. Cite that page when you repeat any of those cells: https://docs.waf.chaitin.com/en/home

Read the SafeLine columns as a pair. On that sample set, the Balance row shows a lower false-positive figure than the Strict row, and also a lower detection figure. Accuracy is slightly higher for Balance than for Strict. That is the only numeric tradeoff these sources provide. It is the vendor's published comparison, not a lab result you re-ran, and it is not a promise that your checkout, upload, or JSON API will match the sample mix.

The other columns are a warning against chasing the smallest false-positive cell. CloudFlare Free is listed at the same 0.07% false positive as SafeLine Balance, with detection at 10.70%. ModSecurity Level 1 is listed at 17.58% false positive. A low false-positive figure, taken alone, is not coverage. Quote detection beside it every time.

If someone asks you to just lower false positives, the honest answer from these pages is narrow. The published Balance row is the lower false-positive SafeLine column, and it does not keep the Strict detection number. Do not invent a third column. Do not tell stakeholders you can hold 76.17% detection and 0.07% false positives at the same time. The table does not show that combination, and these pages do not document a console path for selecting either label.

Confirm the application record before you touch policy

SafeLine is described as a web application firewall developed on nginx. It acts as an HTTP and HTTPS reverse proxy: clients reach SafeLine, SafeLine filters malicious HTTP and HTTPS traffic, and safe traffic is forwarded to the original application. In the web admin console you open Applications, choose Add Application, and enter a domain, hostname, or IP, a listen port such as 80 or 443, and an upstream address. HTTPS apps need the SSL option checked. You then resolve that domain to the IP of the server running SafeLine. The protecting-an-application page is the source for that flow: https://docs.waf.chaitin.com/en/GetStarted/AddApplication

This step removes a whole class of fake false positives. If DNS still points at the origin, SafeLine is not in path, and a block you see elsewhere is not this detector. If the upstream is wrong, users fail even when detection would have forwarded them. If the listen port or SSL flag does not match how browsers connect, the failure is routing. Write those checks down: domain, port, SSL, upstream, and DNS to the SafeLine host. Only after they match should a blocked legitimate request be treated as a detection question.

Split policy blocks from detection errors

The home page lists defenses for web attacks, proactive bot abused defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. Attack blocking is described for SQL injection, XSS, code injection, OS command injection, CRLF injection, XXE, SSRF, path traversal, and related classes. The introduction also names LDAP injection, XPath injection, RCE, backdoor, bruteforce, HTTP flood, and bot abuse. Rate limiting throttles traffic over defined limits, including DoS, bruteforce attempts, and surges. A CAPTCHA challenge is documented as allowing human users and blocking crawlers and bots. An authentication challenge blocks visitors who do not enter the password. Dynamic protection, when turned on, encrypts HTML and JS on each visit.

Those extra controls can interrupt a client that sent no injection payload. A health check that exceeds a rate limit, a script that cannot pass CAPTCHA, or a visitor stopped by the password challenge is consistent with the feature list. Label it as that control. If you dump those events into a false-positive spreadsheet, the next fix will be to weaken attack blocking, which does not change the control that actually fired.

Dynamic protection is easy to misread. Encrypted HTML and JS can break a client that expected the origin markup. That is the feature working as described, not the SQL injection check misfiring. Note it separately in the incident, then decide whether that control should stay on. Do not record it as a signature error.

Re-test with the cases the docs already publish

The application guide includes sample requests for a protected site: SQL injection, XSS, path traversal, code injection, and XXE. You replace the example domain with yours. A blocking page means the attack was defended. The web console attack list, and the detail view on an event, is how the docs say to inspect it.

Run those five cases after you change anything about how traffic reaches the app. If they still produce a blocking page and an attack detail, the defenses described in the guide are still in front of the origin. If a normal user flow fails while those cases still block, return to the application record and to rate limiting, CAPTCHA, authentication challenge, and dynamic protection. Do not close the ticket by disabling attack defense. These sources never say that turning defenses off is a false-positive remedy, and they never publish a bypass list to compensate.

A checklist you can paste into the incident

  1. Quote the Balance and Strict rows, including the 33669 sample count. Do not round the false-positive cells into about zero, and do not merge the two rows.
  2. Confirm the application domain, listen port, SSL option, and upstream against the origin you meant to protect.
  3. Confirm DNS for that domain points at the SafeLine server.
  4. List rate limiting, CAPTCHA, authentication challenge, and dynamic protection as on or off. Blocks from an enabled control stay in that column.
  5. Replay the documented SQL injection, XSS, path traversal, code injection, and XXE cases. Keep the blocking page and the attack detail with the ticket.
  6. If you still need a lower published false-positive figure than the Strict row, say that the Balance row is the comparison the docs provide, and state the detection drop that comes with it. Stop there. Do not add an exception rule these pages do not describe.

That sequence will not make every legitimate request succeed. It will stop you from reducing false positives by deleting the only attack coverage the evaluation actually measured.

Does Balance mean fewer false positives on my site?

Only as a published comparison. On 33669 samples, Balance is 0.07% false positive and Strict is 0.22%. Your forms are not itemized in that table. Use the row as the citation, not as a service-level promise.

Will fewer false positives let more attacks through?

In that same table, yes as a detection tradeoff: 71.65% on Balance versus 76.17% on Strict. Accuracy is 99.45% versus 99.38%. Quote both columns together so nobody hears only the false-positive side.

Is a CAPTCHA or password page a false positive?

Not under the feature descriptions. CAPTCHA is for letting humans through and blocking crawlers and bots. Authentication challenge blocks visitors who do not enter the password. A human stuck on either page is a control problem. It is not evidence that XSS detection is wrong.

What if the attack list is empty?

Recheck domain, port, upstream, and DNS. The detail button is documented for events in the attack list, not as a false-positive export. An empty list means you do not yet have a detector event to argue about.

Do install commands change the false-positive numbers?

No. The deploy guide covers Linux, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, the data directory, and the admin reset command. None of that is a detection-tuning procedure. Keep it out of the false-positive review: https://docs.waf.chaitin.com/en/GetStarted/Deploy

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)