DEV Community

禾
禾

Posted on

How to Check a WAF Before Placing It Behind a CDN

#waf #cdn #proxy #checklist

Putting a web application firewall behind Cloudflare or any other CDN sounds like a routing tweak. For SafeLine, it is not a documented setup. This is a placement checklist: what the official pages actually require, what a CDN changes, and which assumptions you should refuse until you have proof from your own path.

SafeLine is a self-hosted web application firewall. The product introduction describes a reverse proxy placed in front of a web application so clients pass through the WAF before they reach the server. It filters and monitors HTTP and HTTPS traffic, blocks malicious requests, and is described as preventing unauthorized data from leaving the app. The same page lists core capabilities as defenses for web attacks, proactive bot abused defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. Named attack classes include 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).

The application guide narrows the traffic contract. SafeLine is built on nginx. It receives traffic for the original site, cleans malicious traffic, and forwards the remaining traffic to the original application. In the web console you add an application with a domain, hostname, or IP, a listen port such as 80 or 443, the SSL option for HTTPS apps, and an upstream, which is the real address used for forwarding. The documented follow-up is explicit: resolve the domain you entered to the IP address of the server where SafeLine runs (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

That DNS step is the collision. A CDN normally wants the public name to resolve to the CDN, while the CDN fetches some origin. The SafeLine application page wants that same name to resolve to SafeLine. The install guide and the application guide do not describe a Cloudflare origin mode, a generic CDN mode, a trusted-proxy list, or a way to restore the visitor address. If you point the hostname at a CDN, you have left the documented onboarding path. You may still test whether requests can arrive at SafeLine in a shape that matches its reverse-proxy role. You should not describe that test as a supported integration.

Work through the checks below before you change public DNS.

Write down the request SafeLine will actually receive. Documented inspection starts when traffic hits the listen port for that application. Caching, TLS termination, connection reuse, and request rewriting at a CDN are outside these sources. If you cannot say which method, path, headers, and body arrive intact, do not assume a policy written for direct clients will see the browser request.

Keep the upstream field pointed at the real application. A CDN does not replace it. The documented model is still SafeLine receiving the site traffic and forwarding cleaned requests to the upstream you configured (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Inserting a CDN on the public side does not create a second, undocumented origin protocol.

Treat IP controls as dependent on the address SafeLine observes. The home page lists IP-based rate limiting and a web access control list. Rate limiting is described as throttling traffic over defined limits to defend against DoS attacks, brute force attempts, traffic surges, and other abuse (https://docs.waf.chaitin.com/en/home). Nothing on these pages says SafeLine recovers the original visitor from a CDN or from a forwarding header. If the only addresses that arrive belong to the CDN, a limit or an allow entry may apply to the proxy fleet rather than to a person. Measure the recorded client address on a test host before you enforce either control. Do not add a header rule these documents never publish.

Separate visitor challenges from shared caching. Captcha challenge is documented as allowing human users through while blocking crawlers and bots. Authentication challenge, when turned on, requires the visitor to enter the password or be blocked. Dynamic protection encrypts HTML and JS on each visit (https://docs.waf.chaitin.com/en/home). Those behaviors are visitor-facing, and dynamic protection is per visit. A cache in front could store a challenge page, a block page, or an encrypted document and hand it to a later client. The supplied pages do not say those responses are safe to cache. Until a test on your own name proves otherwise, do not cache HTML or JS while dynamic protection is on, and do not treat a CDN bot feature as a replacement for the captcha or the authentication challenge.

Do not turn the published evaluation table into a stacking guide. On 33669 samples, the home page lists CloudFlare Free at 10.70 percent detection, 0.07 percent false positive, and 98.40 percent accuracy; SafeLine Balance at 71.65 percent detection, 0.07 percent false positive, and 99.45 percent accuracy; and SafeLine Strict at 76.17 percent detection, 0.22 percent false positive, and 99.38 percent accuracy (https://docs.waf.chaitin.com/en/home). Those rows compare detection profiles in that table. They do not measure a SafeLine origin behind CloudFlare, cache behavior, or failover. Read them only as evidence that an edge filter and this WAF are different controls.

Leave installation requirements on the SafeLine host. The deploy guide asks for Linux, x86_64 or arm64, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, and at least 1 CPU core, 1 GB of memory, and 5 GB of disk, plus the ssse3 CPU instruction. An ARM install requires a Pro license, and the Personal Edition is not supported on ARM (https://docs.waf.chaitin.com/en/GetStarted/Deploy). A CDN in front of the public site does not relax any of that. The documented console example is HTTPS on port 9443. These pages do not tell you to publish that management port through the CDN.

The layout that stays inside the docs is the published one. Public DNS for the application domain points at the SafeLine server. SafeLine listens on the port you configured. Clean traffic is forwarded upstream. If you still want a CDN ahead of that path, label it an operator experiment. On a name that is not production, prove four facts: the request that arrives is complete enough for the documented filtering role, the IP controls match the identity you intend, challenge pages and encrypted HTML or JS are not reused across visitors, and the upstream receives what SafeLine forwards rather than a side path around it. After that path is stable, the application guide points at attack-class checks such as SQL injection, XSS, path traversal, code injection, and XXE on your own domain. A block page, plus an attack entry whose detail you can open in the console, is the documented sign that inspection fired (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Those checks do not certify the CDN hop.

If a proof fails, put the public name back on the SafeLine address from the application guide. Use a CDN on hostnames that do not depend on per-visit encryption or on a visitor IP these pages never say is restored. Do not close the gap with an unsupported connector, a hidden allow list, or a header convention that is not in the install or application documents.

Does SafeLine document a Cloudflare or CDN origin mode?

No. The application page tells you to add the site in the console and resolve that domain to the SafeLine server IP. The install page covers the host and containers. Neither page documents Cloudflare origin settings, a generic CDN mode, or a supported proxy in front of SafeLine.

Should public DNS point at the CDN or at SafeLine?

For the documented setup, point the application domain at the SafeLine server after you add the application. Pointing it at a CDN leaves that quickstart. You can test the other order yourself. These sources do not promise that it will behave like the direct reverse-proxy path.

Will IP rate limits still see the real visitor?

Only if the address SafeLine observes is the visitor. IP-based rate limiting and the web access control list are listed capabilities, but the docs do not describe restoring a client address from a CDN. Check the address recorded on a test request before you enforce an IP rule.

Can dynamic protection sit behind a shared cache?

The home page says HTML and JS are dynamically encrypted on each visit. It does not say a CDN may cache those responses. A shared cache can cross visitors or replay a challenge page. Leave those responses uncached unless your own test shows a safe exception.

What smoke test is fair once the path is stable?

Exercise the attack classes named in the application guide, on your own domain, and look for the block page and an attack detail in the console. That shows SafeLine inspected the request it received. It does not show that a CDN hop is supported, and it does not replace the four proofs above.

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)