A false positive is not one event. On a reverse-proxy web application firewall, a blocking page, a captcha, a password prompt, and a throttled client can all look the same to the person who filed the ticket. Reducing false positives starts by naming which outcome you actually saw, then checking it against published detection data and the controls that were enabled. This checklist stays inside what the SafeLine documentation states. It does not assume an allowlist syntax, a custom exception API, or a tuning command that the cited guides do not describe.
SafeLine sits in front of the application as an HTTP and HTTPS reverse proxy. Clients reach the firewall first. It filters and monitors traffic, then forwards traffic it treats as safe to the upstream application. The product documentation describes that decision as policy: a set of rules that separate malicious HTTP traffic from safe traffic. Documented attack coverage includes SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, brute force, HTTP flood, and bot abuse (https://docs.waf.chaitin.com/en/home). If a legitimate request contains a string that resembles one of those patterns, a detection block is possible. That is the narrow meaning of a semantic false positive. Every other interruption needs a different check.
Separate detection blocks from intentional controls
The same documentation lists controls that interrupt clients on purpose. IP-based rate limiting throttles traffic that exceeds defined limits, including denial-of-service patterns, brute-force attempts, and traffic surges. A captcha challenge is meant to admit human users and block crawlers and bots. An authentication challenge requires a password, and visitors who do not enter it are blocked. Dynamic protection encrypts HTML and JavaScript on each visit when that control is turned on (https://docs.waf.chaitin.com/en/home). None of those behaviors is described as a detection false-positive setting. If a checkout client, a monitoring probe, or a partner integration fails, confirm whether rate limiting, captcha, authentication, or dynamic encryption is enabled before you treat the event as a signature mistake.
Use a three-way label on every ticket:
- Detection false positive: a normal request was classified as an attack such as SQL injection, XSS, or path traversal.
- Control interruption: the client hit a rate limit, a captcha, or a password challenge.
- Content change: dynamic protection rewrote HTML or JavaScript, which can surprise a client even when the request was not blocked as an attack.
Write that label into the ticket before anyone debates signatures. A later change in detection posture will not fix a password challenge, and turning off a challenge will not fix a real injection match.
Read Balance and Strict as a tradeoff, not a slogan
The effect evaluation on the product home page is the documented quantitative evidence for false positives. It uses 33,669 samples for each row. SafeLine Balance is listed at 71.65 percent detection, 0.07 percent false positives, and 99.45 percent accuracy. SafeLine Strict is listed at 76.17 percent detection, 0.22 percent false positives, and 99.38 percent accuracy. In the same table, ModSecurity Level 1 is listed at 69.74 percent detection and 17.58 percent false positives, and CloudFlare Free is listed at 10.70 percent detection and 0.07 percent false positives (https://docs.waf.chaitin.com/en/home).
Read those rows as a tradeoff, not as a promise about your own routes. Strict detection is higher, and the published false-positive rate is also higher. Balance keeps the published false-positive rate at 0.07 percent, the same figure shown for CloudFlare Free in that table, with lower detection than Strict. Accuracy is slightly higher for Balance than for Strict in the published table. If the goal is specifically to reduce false positives, the documented comparison points toward the Balance row rather than the Strict row. The guides cited here do not describe a console path or a command for switching those labels, so do not invent one. Treat the table as the decision input. Do not assume a documented switch exists until you can see one in your own deployment.
Do not extend the table either. It does not report latency, bypass rates on your application, or results for a custom rule pack. If you need a number the page does not publish, leave it unstated.
Confirm the attack list belongs to the right application
A false-positive review is useless if the record belongs to a different site. The application guide says SafeLine is a web application firewall developed based on nginx. It receives traffic for the original website, cleans malicious attack traffic, and forwards safe and reliable traffic to the original application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). When you add an application you set Domain, Port, an SSL option for HTTPS apps, and Upstream. Domain can be a domain name, a hostname, or an IP address. After that, you resolve the entered domain to the IP address of the server where SafeLine is located.
Before you call a block a false positive, check four facts:
- The domain or hostname on the request matches the application entry.
- The listening port, and the SSL option for HTTPS, match how clients actually connect.
- Upstream is the real address of the original application, not a stale host.
- The attack-list entry you opened is for that same application, and you opened detail rather than judging from the summary line alone.
The application guide also shows what a successful defense looks like. Sample probes for SQL injection, XSS, path traversal, code injection, and XXE should produce a blocking page, and the console attack list should show the event. Open detail for the specific record (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Use those samples only on a host you are authorized to test, and replace the example domain with your own, so you know the shape of a true positive. A legitimate URL that lacks those payloads and still appears in the attack list is the record worth keeping.
Run the checklist without undocumented features
Work in this order. Stop when the cause is explained.
- Save the full request: method, path, query string, the headers you are allowed to store, and the response the user saw.
- Label it as a detection block, a rate limit, a captcha, an authentication challenge, or a dynamic-protection side effect. Only the first label is a semantic false positive.
- Open the attack list and the detail view. If there is no detection record, do not force the event into the detection bucket.
- Compare the payload with the documented attack examples. A union-select string, an onerror handler, a traversal sequence, a code-injection string, or an XXE doctype is not a false positive just because a tester sent it on purpose.
- If the request is ordinary application traffic and it was detected, note the published Balance versus Strict false-positive gap before you ask for a broader bypass.
- If the interruption came from rate limiting, captcha, or authentication, change the question. Ask whether that control should apply to this client. The documentation defines what those controls do. It does not define a per-URL exception language in the pages cited here.
- After any posture change you can actually confirm, re-test one known-bad sample and one known-good business URL. You want the bad sample blocked and the good URL absent from the attack list.
This sequence reduces false positives by refusing to mix causes. It also avoids promising an integration, a rule dialect, or a whitelist feature that these sources do not provide. If a review needs an exception mechanism, say that the cited guides do not document one, and keep the evidence pack: request, detail view, control state, and which published row you were comparing.
Does a lower false-positive rate always mean better protection?
No. In the published evaluation, Balance shows 0.07 percent false positives and 71.65 percent detection. Strict shows 0.22 percent false positives and 76.17 percent detection. Accuracy is 99.45 percent for Balance and 99.38 percent for Strict (https://docs.waf.chaitin.com/en/home). Lower false positives in that table come with lower detection. Pick the row that matches the risk you accept, and do not describe either row as universally better.
How do I tell a detection block from a challenge or a rate limit?
Check the user-visible result and the console record together. A detection event should appear in the attack list, and detail should describe that event (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A captcha, a password prompt, or throttling matches the documented captcha challenge, authentication challenge, or rate limiting behavior (https://docs.waf.chaitin.com/en/home). If the console has no attack detail, treat the case as a control interruption until evidence says otherwise.
Should I send the sample attack URLs to a live customer site?
Use them only on an application you are authorized to test, and replace the example domain with your own, as the guide instructs (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Their job is to show what a blocking page and an attack-list entry look like. They are not a false-positive test. A probe that contains a union select or a path-traversal sequence is expected to be blocked.
What if I cannot find an allowlist or exception command?
Do not invent one. The cited home page and application guide describe proxy setup, attack defense, rate limiting, captcha, authentication challenge, dynamic protection, and the Balance versus Strict evaluation. They do not document a false-positive exception syntax. Reduce noise by classifying the event, reviewing attack detail, and choosing the published row whose false-positive rate matches your goal.
What should the next reviewer keep so the debate is not repeated?
Keep the request URL, the control that was enabled, whether attack detail existed, and the published figures you used: sample count 33,669, Balance false positives 0.07 percent, and Strict false positives 0.22 percent (https://docs.waf.chaitin.com/en/home). Also keep the application domain, port, SSL choice, and upstream (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). That pack is enough to decide whether the next step is a posture review or a control-scope review.
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.