Coder Legion - Recent posts tagged falsepositives

How to Reduce WAF False Positives by Classifying the Block First

Sun, 25 Oct 2026 02:25:24 +0000

A blocked legitimate request is a false positive. Cutting those blocks is useful only if the same change still stops the attacks you deployed the firewall to catch. SafeLine is a self-hosted web application firewall that filters and monitors HTTP traffic between a web application and the Internet, using policies to separate malicious requests from safe ones (https://docs.waf.chaitin.com/en/home). The supplied documentation does not describe a false-positive exception form, a per-field allow command, or a numeric sensitivity setting you can edit. What it does describe is a reverse-proxy placement, a console attack list with a detail view, several controls that can deny visitors for reasons other than an injection payload, and a published evaluation that reports different false-positive rates for Balance and Strict. This checklist uses only those facts.

Classify the event before you change policy

SafeLine is an HTTP and HTTPS reverse proxy developed on nginx. It receives traffic for the original site, removes malicious attack traffic, and forwards the remaining traffic to the upstream application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). When a test or a user hits a blocking page, open the web console attack list and click detail. That is the documented place to see what was recorded. A blocking page alone does not tell you whether the deny came from a web-attack policy, a rate limit, a challenge, or an authentication check.

Confirm the protected application is the one you think it is. Adding an application requires a domain, hostname, or IP, a listen port, an SSL option for HTTPS, and the upstream address SafeLine will use to reach the origin. The domain then has to resolve to the SafeLine server (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). If DNS still points at the origin, or the upstream is a stale address, the console will not be a reliable picture of user traffic. Fix that routing first. Lowering detection will not repair a proxy that is not in path.

Separate attack denies from control denies

The product home page lists more than one way a visitor can be stopped. Treating every deny as a signature false positive leads to the wrong fix.

Web-attack defense is aimed at classes such as 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). A detail record in one of those classes, on a request the application must accept, is the usual meaning of a detection false positive.

Other documented controls deny clients that may be legitimate:

IP-based rate limiting throttles traffic that exceeds defined limits. The stated uses are DoS attacks, brute-force attempts, traffic surges, and other abuse (https://docs.waf.chaitin.com/en/home). A busy user or a health check can cross a limit that was set for abuse.
A CAPTCHA challenge is described as allowing human users while blocking crawlers and bots (https://docs.waf.chaitin.com/en/home). A client that cannot complete the challenge will be blocked even if the URL contains no attack payload.
An authentication challenge blocks visitors who do not enter the password (https://docs.waf.chaitin.com/en/home). That is an access gate, not a statement that the request was an exploit.
Dynamic protection, when turned on, encrypts HTML and JavaScript on each visit (https://docs.waf.chaitin.com/en/home). The docs do not call this a false-positive control. After you enable it, verify that the pages users need still work, instead of assuming encryption is unrelated to support tickets.
A web access control list is named as a core capability (https://docs.waf.chaitin.com/en/home). The supplied pages do not publish rule syntax, so this checklist does not invent an allow entry.

Write the class down in one sentence before you touch configuration. A search query blocked as SQL injection is a detection question. A checkout refresh blocked after the rate limit is a limit question. An API client blocked by CAPTCHA is a challenge question. Each one has a different next step.

Read Balance and Strict as a published tradeoff

The effect-evaluation table is the only false-positive measurement in the supplied sources. It uses 33,669 samples for each row (https://docs.waf.chaitin.com/en/home):

SafeLine Balance: detection 71.65 percent, false positive 0.07 percent, accuracy 99.45 percent.
SafeLine Strict: detection 76.17 percent, false positive 0.22 percent, accuracy 99.38 percent.

The same table prints ModSecurity Level 1 at 69.74 percent detection and 17.58 percent false positive, and the CloudFlare row labeled Free at 10.70 percent detection and 0.07 percent false positive. Those are the figures printed on that page. They are not a procedure for editing your own rules, and they are not a forecast for your application.

On that sample set, Strict detects more and also shows the higher false-positive rate. Balance shows the lower false-positive rate, 0.07 percent, and a lower detection rate than Strict. If the detail view shows ordinary application text being classed as an attack, and your priority on this published comparison is the lower false-positive figure, Balance is the row that matches that priority. If missing attacks matters more than the gap between 0.07 percent and 0.22 percent false positives, Strict is the row that matches that priority. Neither row means false positives are gone.

Operator checklist

Reproduce one blocked journey. Open the attack list and click detail. Record the class of the event. If there is no attack detail, do not invent a signature bypass.
Check domain, port, SSL, and upstream against the real origin, and check that the domain resolves to the SafeLine host. Correct a proxy miss before you discuss detection.
If the detail is a rate limit, CAPTCHA, or authentication result, adjust the question to that control. Turning off web-attack inspection will not explain a password challenge, and leaving a tight limit on a busy path will keep blocking people who never sent an exploit.
If the detail is a web-attack class on traffic you must allow, choose Balance or Strict using the published detection and false-positive pair. Record which figure you are optimizing for.
After any change, replay the documented samples against your own domain: a union-select SQL injection, an image-handler XSS payload, a path traversal toward /etc/passwd, a code-injection payload, and an XXE doctype (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A blocking page means that sample was defended. If those samples now succeed, coverage dropped. That is not a false-positive fix.
Replay a known-good journey in the same window: a normal page load, a form post with everyday punctuation, and a repeat request that should stay inside your rate limit. If dynamic protection is on, confirm HTML and JavaScript still behave for that journey, because the feature re-encrypts them on each visit.
Keep the detail note with the decision. A later reviewer should be able to see why Balance or Strict was chosen, and which control, if any, was the real source of the deny.

The deploy guide is not a tuning guide. It specifies Linux, x86_64 or arm64, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, a minimum of 1 CPU core, 1 GB memory, and 5 GB disk, plus an ssse3 CPU check (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Those requirements tell you whether the instance can run. They do not set a false-positive budget. Environment values such as the console port, image tag, and Postgres password are install settings, not detection settings. Do not add unofficial scripts to suppress a parameter the console has already classified.

FAQ

How do I tell a false positive from a normal block?

Match the detail view to a request the application is supposed to accept. A web-attack class on that request is a false-positive candidate. A rate-limit, CAPTCHA, or password result can be unwanted, but it is a control outcome, not proof that attack detection misfired.

Will Balance mode remove false positives?

No. On the published 33,669-sample table, Balance shows a 0.07 percent false-positive rate, and Strict shows 0.22 percent. Lower is not zero, and the table is not your production log.

Should every path use CAPTCHA and authentication?

Not as a false-positive remedy. CAPTCHA is for separating human users from crawlers and bots. Authentication challenge blocks visitors who do not enter the password. Use them where that behavior is what you want. Applying both on every path will deny clients that web-attack detection would have forwarded.

Where is the blocked request explained?

In the web console attack list. Click detail to see the recorded event after the blocking page appears (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

Can the install steps configure fewer false positives?

No. Installation covers the host requirements, the compose file, environment variables, starting the stack, and resetting the administrator account (https://docs.waf.chaitin.com/en/GetStarted/Deploy). False-positive decisions belong in the review checklist above: classify the detail, fix proxy setup, then choose between the published Balance and Strict figures and retest both attack samples and known-good journeys.

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.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

How to Reduce WAF False Positives With a Cause Checklist

Sun, 25 Oct 2026 02:24:52 +0000

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.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto