How to Test If Your WAF Is Working: Block Page and Attack Log

A site that loads through a proxy is not evidence that the proxy is filtering attacks. Reachability, a valid certificate, and a normal upstream response only show that requests can pass. For SafeLine, the documented way to test the control is stricter: send the published probe requests to the domain that actually resolves to SafeLine, require the blocking page, and require the same attempt to appear in the web console attack list.

SafeLine is a self-hosted web application firewall. Deployed in front of an application, it acts as an HTTP and HTTPS reverse proxy: it accepts traffic for the original site, filters and monitors it, blocks what its policies treat as malicious, and forwards the remaining traffic upstream. The introduction describes that role as a shield between the application and the internet. Clients reach the WAF before they reach the origin, which is the opposite of a forward proxy that hides a client. The same pages list the attack classes this filtering is meant to cover, including SQL injection, cross-site scripting, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, remote code execution, XXE, SSRF, path traversal, backdoors, brute force, HTTP flood, and bot abuse. Source: https://docs.waf.chaitin.com/en/home and https://docs.waf.chaitin.com/en/GetStarted/AddApplication

Placement is the first test condition. In the admin console, an application is added with three facts that the probe depends on: the domain, hostname, or IP clients will use; the port SafeLine listens on, such as 80 or 443; and the upstream address of the real application. HTTPS applications need the SSL option enabled. After those fields are saved, the domain has to resolve to the SafeLine server, not to the origin. If it does not, every later request is a test of something else. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication

Two signals, one probe

The configuration guide does not stop at adding the site. It publishes sample requests and says to replace the example host with your own domain. The samples are a SQL injection query (id=1 and 1=2 union select 1), a cross-site scripting query that uses an image tag with an error handler calling alert, a path traversal query that walks up toward /etc/passwd, a code injection query that calls phpinfo() and system('id'), and an XXE query that begins an XML document and declares an external entity. Those are the vendor's own examples for a common-attack check. They are not a private exploit kit, and they are not a full matrix of every class named in the introduction.

The guide's pass condition on the client is specific: you should see the blocking page. That page is how SafeLine tells you the attack was defended. The second signal is in the product, not in the browser. Open the web console, find the attempt in the attack list, and click detail. After installation, that console is the Web UI at https://<safeline-ip>:9443/. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication and https://docs.waf.chaitin.com/en/GetStarted/Deploy

I want both signals before I call the path protected. They can fail independently. A blocking page with no attack-list row may mean the browser never hit this SafeLine instance: wrong DNS answer, wrong port, or a different proxy returning its own error. An attack-list row without a blocking page may mean the logged request and the request you watched were not the same request. The useful result is agreement on one host, one scheme, and one probe: the client is blocked, and detail in the console describes that attempt.

Keep the claim as narrow as the evidence. The introduction names more attack classes than these five samples exercise. A blocked SQL injection sample supports that sample on that path. It does not, by itself, prove OS command injection coverage, SSRF coverage, or flood control. Repeat the documented samples you care about, and write down the classes you did not send.

Do not borrow one feature's result for another

The feature list is wider than attack blocking. Documented capabilities include defenses for web attacks, proactive bot-abuse defense, HTML and JavaScript code encryption, IP-based rate limiting, and a web access control list. Rate limiting is described as throttling traffic that exceeds defined limits, including denial-of-service attempts, brute force, and traffic surges. CAPTCHA challenge is described as allowing human visitors while blocking crawlers and bots. Authentication challenge, when turned on, requires a password or the visitor is blocked. Dynamic protection, when turned on, encrypts HTML and JavaScript from the web server on each visit. Source: https://docs.waf.chaitin.com/en/home

None of those behaviors is what the five query-string probes measure. A block page on the XSS sample does not show that a password gate is on, that a bot received a CAPTCHA, that an address was rate limited, or that page source was encrypted for that visit. If you enabled one of those controls, test the behavior the documentation actually assigns to it. If you did not enable it, do not report it as verified.

Published evaluation numbers are a third thing, and they are not your site. The home documentation reports an effect evaluation over 33,669 samples. In that table, 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. The same table includes a ModSecurity Level 1 row and a CloudFlare Free row. Treat that as a lab summary published by the project, not as a measurement of your domain, your upstream, or the policy you have turned on today. The live test remains the blocking page plus the matching attack-list detail. Source: https://docs.waf.chaitin.com/en/home

Before you record a pass

Use a short sequence and stop at the first failed condition.

Confirm the application entry has the domain, listen port, and upstream you think you are testing. Confirm public DNS for that name points at the SafeLine server. Request the site the way a client will, including TLS if you checked SSL. Send each documented probe to your domain rather than to the example host in the guide. Require the blocking page. Require a matching attack-list entry, then open detail. Separately note rate limiting, CAPTCHA, authentication challenge, and dynamic protection as untested unless you observed the behavior each feature describes.

If a probe is executed by the origin instead of being blocked, SafeLine is not on that request path. The operating model is that SafeLine receives the traffic, removes malicious requests, and forwards what remains. Fix resolution and the application entry before you interpret any other result. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication

Does a successful homepage load mean the WAF is working?

No. It means the reverse proxy can fetch the upstream and return a normal response. The documented sign that an attack probe was defended is the blocking page, confirmed in the attack list.

Why check the console if I already saw a block page?

The block page is the client signal. The attack list is the product signal that this SafeLine instance saw and recorded the attempt. Open detail so you are not matching a generic error from another hop.

Are the five sample queries a full coverage test?

No. They are the common-attack examples in the configuration guide: SQL injection, XSS, path traversal, code injection, and XXE. Other classes named in the introduction, and the rate-limit and challenge features, need their own evidence.

Should the probe target the origin IP?

Not when the question is whether SafeLine is filtering the site. Traffic sent straight to the origin never enters the reverse proxy. Use the domain that resolves to the SafeLine server and the port SafeLine is listening on.

Can the published detection percentages replace a live test?

No. Those figures are an effect evaluation on a fixed sample set in the documentation. They do not describe your hostname, your upstream, or the request you just sent.

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/bvK1BAV
• 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