DEV Community

Lia
Lia

Posted on

How to Decide Whether a WAF Belongs Behind a CDN

#waf #cdn #proxy #checklist

Operators often want a content delivery network to remain the public front door while a web application firewall inspects requests immediately before the origin. That arrangement is a reasonable operations question. It is not a documented SafeLine feature. The supplied product pages do not describe a Cloudflare connector, a generic CDN mode, an origin-pull profile, or a procedure for placing this WAF behind Cloudflare or any other CDN. The practical response is a placement decision, not a pretend integration.

SafeLine is a self-hosted web application firewall. It filters and monitors HTTP traffic between a web application and the Internet. The published model puts it in front of the application as a reverse proxy: clients pass through the WAF before they reach the server. It blocks malicious HTTP and HTTPS traffic and is intended to prevent unauthorized data from leaving the application. That description is in the product introduction at https://docs.waf.chaitin.com/en/home

The application guide states the same model in operational terms. SafeLine is an nginx-based HTTP and HTTPS reverse proxy. It receives traffic for the original website, removes malicious attack traffic, and forwards the remaining traffic to the original application. In the web admin console you open Applications, choose Add Application, and enter three facts: the domain, hostname, or IP of the original app; the port SafeLine will listen on, such as 80 or 443, with the SSL option checked for HTTPS applications; and the upstream, which is the real address of the original app. After those settings, you resolve the domain you entered to the IP address of the server where SafeLine is located. Visitors then reach the protected application through that domain. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication

That last instruction is the conflict. A CDN normally owns the public name and expects the origin to be a private next hop. The SafeLine guide expects the application domain itself to resolve to the SafeLine server. The sources do not provide a second onboarding path, a provider allowlist, or a header contract that reconciles those two requirements. If the CDN must remain the only public resolution target, you are outside the written procedure.

Before changing records, write down which system clients must resolve. If the documented requirement is that the application domain points at SafeLine, pointing that same name only at a CDN does not complete the published setup. Decide which statement wins before you edit DNS. A diagram that looks tidy in a ticket is not a substitute for that choice.

Separate the previous hop from the upstream. In the documented model, the upstream is the original application. A CDN is not described as an upstream, and SafeLine is not described as a CDN origin. You can sketch a chain in which the CDN connects to SafeLine and SafeLine connects to the app. That sketch is an operator hypothesis. These pages do not document it, and this article will not fill the gap with invented origin settings, authenticated pulls, or provider headers.

Then ask which requests will actually arrive. Documented 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, among others. Listed core capabilities are defenses for web attacks, proactive bot defense, HTML and JavaScript code encryption, IP-based rate limiting, and a web access control list. The feature pages also describe rate limiting for denial-of-service patterns, brute-force attempts, traffic surges, and other abuse; CAPTCHA challenges that admit human visitors and block crawlers and bots; an authentication challenge that requires a password; and dynamic protection that encrypts HTML and JavaScript on each visit. Those controls apply to traffic SafeLine receives. A response served entirely from a CDN cache never enters that path, so the WAF cannot inspect it or encrypt it on that visit. Source: https://docs.waf.chaitin.com/en/home

Treat visitor identity as a hard stop. Rate limiting is documented as IP-based, and the access control list is a core capability. The sources do not describe trusting a CDN visitor-IP header, restoring the original client address, or allowlisting provider egress ranges. If SafeLine observes only a small set of CDN egress addresses, IP limits and IP allow or deny rules key off those shared addresses. Individual visitors collapse into one identity. Do not invent a header toggle to hide that result. The correct outcome of the check is to withhold per-visitor IP policy until the address SafeLine sees is the address you intend to govern.

Challenges and dynamic encryption have the same boundary. A CAPTCHA page, a password prompt, and HTML or JavaScript encrypted on every visit all assume the visitor exchange passes through SafeLine. The dynamic-protection wording is specific: HTML and JavaScript from the web server are dynamically encrypted each time you visit. A cache that stores one of those responses and replays it later is not described. Neither is a rule that tells a CDN to bypass cache for challenged paths. If the CDN would cache HTML, challenge pages, or encrypted scripts, stop. Compatibility is not established here.

TLS deserves the same restraint. The add-application flow lets you enable SSL and choose the listen port. It does not document origin certificates, authenticated origin pulls, a required provider header, or a cleartext profile for traffic that a CDN has already decrypted. If you terminate TLS at the CDN and forward to SafeLine, that design is yours. Match it only to the port, SSL option, and upstream you can actually set in the console. Do not assume a hidden CDN profile exists because both sides speak HTTP.

Placement also does not relax the host baseline. The deploy guide requires Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, at least one CPU core, 1 GB of memory, 5 GB of disk, and a CPU with the SSSE3 instruction. An ARM installation requires a Pro license to work properly; the Personal Edition is not supported on ARM. With the documented default, the console is opened at https://:9443/. A CDN in front of the data plane does not change those requirements, and the sources do not say the management port should be published through the CDN. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy

The decision is therefore narrow. Follow the documented path when you can point the application domain at the SafeLine server and set the original application as upstream. If a CDN must keep the public name, pause. These sources contain no procedure for inserting SafeLine behind Cloudflare or any other CDN, no documented way to preserve visitor IP identity in that position, and no statement that caching is compatible with per-visit HTML and JavaScript encryption. Choose one of three outcomes: make SafeLine the public reverse proxy, keep the CDN only on names that do not depend on these WAF controls, or hold the change until the design no longer treats an undocumented hop as supported.

Does SafeLine document a mode for Cloudflare or any CDN?

No. The introduction and the application guide describe a reverse proxy that clients reach directly, then DNS to the SafeLine server. They do not describe a provider integration or a behind-CDN topology.

What fails first if public DNS stays on the CDN?

The documented onboarding step. The application guide tells you to resolve the entered domain to the SafeLine server IP. A CDN-owned public name does not satisfy that step, so the published setup is incomplete until that conflict is resolved.

Will IP rate limiting still see each visitor?

Only if the IP SafeLine observes is the visitor IP you mean to limit. The product documents IP-based rate limiting and a web access control list. It does not document a CDN client-IP header. Shared egress addresses are a reason to withhold per-visitor IP policy, not a prompt for an undocumented workaround.

Are CAPTCHA, password challenge, and dynamic encryption cache-safe?

They are documented as visitor-facing controls on traffic that reaches SafeLine. Dynamic protection encrypts HTML and JavaScript on each visit. Nothing in the sources says a CDN may cache those responses or bypass the WAF for them. If the cache answers first, SafeLine never applies the control.

What should I do instead of forcing the WAF behind the CDN?

Meet the documented host baseline, add the application with domain, port, and upstream, and point that domain at the SafeLine server. Confirm blocking in the console against a site you control. If that DNS change is unacceptable, do not substitute a generic CDN origin tutorial. The missing integration is not supplied here.

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)