A running filter process is not proof that attacks are being stopped. The useful question is whether live client traffic enters the reverse proxy, whether a documented malicious sample is rejected, and whether the console records that same attempt. SafeLine's getting-started pages already define that sequence. Keep the test inside those pages. Do not add private payloads, assumed status codes, or unpublished console fields and then call the result an official pass.
Placement comes before any attack string. The product introduction describes SafeLine as a self-hosted web application firewall that filters and monitors HTTP traffic between a web application and the Internet. Clients pass through this reverse proxy before they reach the origin, and the proxy filters, monitors, and blocks malicious HTTP/S traffic (https://docs.waf.chaitin.com/en/home). The application guide states the operating model directly: SafeLine is developed based on nginx, 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). A request sent only to an origin address that SafeLine does not front never exercises that model.
Add the application before you send a sample. In the web admin console, open the Applications page and click Add Application. Enter the original app domain, hostname, or IP; the port SafeLine will listen on, such as 80 or 443; and the upstream address used to forward traffic. For an HTTPS app, check the SSL option. After saving, resolve the domain you entered to the IP of the server where SafeLine is located. The guide then says you can access the protected application through that domain (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Do that ordinary visit first. If the site does not load, fix the proxy path before you interpret any attack result. If the site loads, you have shown forwarding only. Forwarding is required, and it is not detection.
Use the five published samples next. Replace the example host with your own domain and leave each query string unchanged. The SQL injection sample ends with id=1+and+1=2+union+select+1. The XSS sample ends with id=. The path traversal sample ends with id=../../../../etc/passwd. The code injection sample ends with id=phpinfo();system('id'). The XXE sample places an XML declaration and a DOCTYPE with an empty SYSTEM identifier in the id value, exactly as printed in the application guide (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Access each URL. The documented success signal is the blocking page. The guide says that if you see that page, SafeLine helped defend the attack. If the original application content appears instead, that sample did not pass. Do not invent an exception the document does not list.
A blocking page is only half of the published check. Open the web console and review the attack list. To view the specific details of the attack, click detail (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Do this for every sample. One blocked XSS request does not certify the SQL injection sample, and a list entry whose detail you never open does not finish the workflow the guide describes. After installation, the console page is https://:9443/ (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Reaching that page shows that the management UI is available. It does not show that public DNS sends visitors through the proxy.
Keep later claims inside the sentences the docs actually publish. The introduction lists defenses for 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. Its core capabilities also include proactive bot abused defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list (https://docs.waf.chaitin.com/en/home). The feature pages further describe rate limiting for DoS attacks, bruteforce attempts, traffic surges, and other abuse; a CAPTCHA challenge; an authentication challenge; and dynamic protection that encrypts HTML and JS on each visit (https://docs.waf.chaitin.com/en/home). Those are product descriptions, not extra test steps. The try-it section does not publish a request rate, a challenge password, or a page-source comparison for dynamic encryption. A passed sample set therefore does not prove that rate limiting, CAPTCHA, authentication challenge, or dynamic protection was turned on.
Apply a short pass rule. The application object has the intended domain, listen port, SSL choice, and upstream. The domain resolves to the SafeLine server. A normal request still reaches the protected application. Each of the five documented samples returns the blocking page. Each attempt is visible in the attack list, and detail opens. If a sample is not blocked, recheck placement before looking for a deeper cause. Traffic that never enters the reverse proxy cannot produce a meaningful block or a meaningful attack record. This procedure answers whether the documented path and sample checks succeeded. It does not assign a detection score, compare products, or prove that every named control was exercised.
What does a successful sample test show?
It shows the blocking page for that published URL, then a related row in the attack list whose detail view opens. The application guide uses both the page and the detail click to confirm that the attack was defended and recorded.
Should the sample query strings be edited?
No. Change only the example host to the domain you protected. The guide publishes specific strings for SQL injection, XSS, path traversal, code injection, and XXE. A rewritten payload is a different experiment, and the document does not define that experiment as a pass.
Is a normal page load enough?
No. Once the domain resolves to the SafeLine server, a normal visit shows that safe traffic can be forwarded upstream. Detection still requires a documented malicious sample, the blocking page, and the console detail.
Do five samples prove every listed control?
No. They check the published try-it cases on the path you configured. The product pages name more attack classes, plus rate limiting, CAPTCHA challenge, authentication challenge, and dynamic HTML and JS protection, but they do not give separate verification steps for those controls.
What should be checked when nothing is blocked?
Confirm the application domain, listen port, SSL option, and upstream, then confirm that DNS points to the SafeLine server rather than the origin. The documented design filters traffic that arrives at the reverse proxy. A reachable console does not place the WAF on a hostname clients never use.
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
Top comments (0)