What Is a Web Application Firewall (WAF)?
%203.png&w=256&q=75){kind=small}
What a WAF Actually Filters
A web application firewall inspects the actual content of HTTP and HTTPS requests — the URL, headers, query string, cookies, and request body — and blocks the ones that look malicious before they reach your application code. That places it at Layer 7 of the OSI model, the application layer, which is a fundamentally different job than deciding whether a packet is allowed to reach a given IP address and port at all.
Because a WAF reads the payload, it can catch things a lower-level firewall never sees: SQL injection strings smuggled into a form field, `<script>` tags injected through a comment box for cross-site scripting, path traversal attempts like `../../etc/passwd` in a file parameter, and requests carrying known malicious-bot user-agent signatures. A WAF works from a ruleset — often something like the OWASP Core Rule Set — that pattern-matches these attack shapes and either blocks, challenges, or logs the request depending on how it is tuned.
WAF vs Network Firewall: Why CSF Is Not a WAF
CSF (ConfigServer Security & Firewall) is a network firewall, not a WAF, and the two solve different problems even though people mix them up constantly. CSF operates at Layer 3/4 — it decides whether traffic from a given source IP is allowed to reach a given port at all, based on rules like "allow port 443 from anywhere, block port 3306 from everywhere except localhost, block this IP after five failed SSH logins."
CSF never looks inside an HTTP request body. A visitor whose IP is allowed through on port 443 can send a SQL injection payload in a form field and CSF will pass it straight through to Nginx and PHP-FPM without inspecting it — that request is well-formed at the network level, so there is nothing for a port-based firewall to object to. This is the core distinction: CSF answers "should this connection be allowed to happen," a WAF answers "is the content of this specific request malicious." A server needs both because they cover different attack surfaces — brute-force SSH and port scanning on one side, and SQL injection or XSS carried inside legitimate-looking web traffic on the other.
Before assuming your server is protected against application-layer attacks, confirm what is actually running. A network firewall being active and correctly configured says nothing about whether HTTP request bodies are being inspected — those are two separate checks, not one.
Cloudflare's WAF: The Common Real-World Example
Cloudflare's WAF is the version most site owners actually encounter, and it works by sitting in front of your server at the DNS level rather than on the server itself. Once a domain is proxied through Cloudflare — the orange-cloud setting on a DNS record — every request for that domain resolves to Cloudflare's edge network first, gets inspected there, and only the traffic Cloudflare decides is legitimate is forwarded on to your origin server.
That edge placement is what makes it a genuine WAF rather than a server-side add-on: the malicious request never even reaches your PHP-FPM pool or your database connection, because it was already rejected hundreds of miles away at a Cloudflare data center. This is also why WAF and CDN/DDoS-protection services tend to bundle together commercially — the same edge position that lets Cloudflare filter Layer 7 attacks also lets it absorb volumetric DDoS traffic and cache static assets, so a single DNS change buys three layers of benefit at once.
What CloudStick Provides: Two Complementary Layers
CloudStick pre-configures CSF at server install and integrates directly with Cloudflare, which together cover the network layer and the application layer without requiring a separate paid WAF product. CSF ships active out of the box on every CloudStick server, handling port-level rules, fail2ban integration for brute-force protection, and IP whitelisting or blocking — this is the network firewall layer, and CloudStick is direct that it is exactly that, not a WAF.
For the application layer, CloudStick's Cloudflare integration lets you point a domain's DNS through Cloudflare directly from the dashboard, which is what unlocks Cloudflare's own WAF, its DDoS protection, and Cloudflare Tunnels for staging environments — all as edge-level protection sitting in front of the origin server. Separately, CloudStick's per-site PHP-FPM pools disable dangerous PHP functions like `exec`, `shell_exec`, `system`, `passthru`, `proc_open`, the `posix_*` family, and `symlink`, and enforce `open_basedir` restrictions per site. That is a third, distinct layer — application-level hardening at the PHP runtime — that limits what a script can do even if something malicious does get executed, independent of both CSF and any WAF.
Think of it as three layers, not one: CSF blocks bad connections before they reach a port, Cloudflare's WAF blocks bad requests before they reach your server at all, and disabled PHP functions with `open_basedir` limit the damage of anything that slips through both. None of the three substitutes for the others.
Checking What's Actually Protecting Your Server
Confirming CSF is active tells you nothing about whether a WAF is protecting your application, and it is worth checking both separately rather than assuming one implies the other. A quick status check on the server confirms the network firewall side.
For the WAF side, that check happens off the server entirely — in the Cloudflare dashboard under Security → WAF, where you can see whether managed rules are enabled and review the events log of requests that were actually challenged or blocked at the edge. If a domain's DNS record is grey-clouded (DNS-only) instead of orange-clouded (proxied) in Cloudflare, no WAF inspection is happening at all, regardless of anything CSF is doing on the origin server.
Do You Need a Dedicated WAF?
Any site handling forms, logins, search fields, or user-generated content benefits from a WAF, because those are exactly the input points SQL injection and XSS attacks target. A brochure site with no forms and no dynamic input has a smaller attack surface, but WordPress sites, e-commerce stores, and anything with a login page are common WAF targets precisely because they accept and process user input constantly.
The cheapest, most common WAF deployment is still routing a domain through Cloudflare and turning on its managed rules — it costs nothing on Cloudflare's free tier, requires no server-side software, and protects every request before it ever reaches the origin.
Since CloudStick already gives you CSF as the network layer out of the box and a direct Cloudflare integration for DNS management, adding the application layer is a matter of proxying the domain through Cloudflare from the CloudStick dashboard rather than standing up separate infrastructure. The three layers — network firewall, edge WAF, and PHP-FPM hardening — stack without conflicting, and each one covers ground the other two do not touch.
