A network firewall decides whether a connection to port 443 is allowed. A WAF reads what is inside that connection, meaning the URL, headers and request body, and blocks known attack patterns before they reach the application.
A network firewall works with IP addresses, ports and protocols: it allows 443 and refuses 3306. It does not know what an HTTP request is, so it lets through anything that reaches the allowed port, including a SQL query injected into a login form. A WAF sits in front of the application and decodes the request: it recognises ' OR 1=1 in a parameter, a script in a comment field, an attempt to read /etc/passwd through directory traversal. The two filters work together, at different layers.
You need a WAF when the application contains code you do not fully control, such as WordPress plugins, when published vulnerabilities are exploited within hours and you need days to patch, or when you expose a public API. A WAF buys time but does not fix the cause: the flaw stays in the code and a patient attacker finds a payload the rule does not catch. False positives are the cost, so start in detection mode, read the logs for a week and exclude the rules that hit legitimate traffic.
| WAF type | Where it runs | Main advantage | Limit |
|---|---|---|---|
| Hosting-level | On the hosting server, for all accounts | Active by default, no configuration | Generic rules, limited tuning |
| On the server (ModSecurity + OWASP CRS) | In Nginx or Apache, in front of the application | Full control over the rules | Needs maintenance and log reading |
| Cloud (DNS change) | In the provider's network, before the server | Also absorbs L7 DDoS, updated centrally | Traffic passes through a third party; the origin must stay hidden |
# /etc/modsecurity/modsecurity.conf
SecRuleEngine DetectionOnly
SecAuditEngine RelevantOnly
SecAuditLog /var/log/modsec_audit.logSecRule REQUEST_URI "@beginsWith /api/filter" \
"id:10001,phase:1,pass,nolog,ctl:ruleRemoveById=942100"A vulnerability in an invoicing plugin was published on Monday, and the patch arrived on Thursday. The hosting-level WAF blocked exploitation attempts in the meantime, visible in the logs from Tuesday. Without a WAF, the exposure window would have been three days.
A generic SQL injection rule blocked a legitimate endpoint that received filter queries with AND and OR operators. The team excluded the rule for that endpoint only, added schema validation on the request body and kept the rest of the ruleset active.
A plugin runs in PHP, so the request has already reached the application and uses resources. A hosting-level or web-server WAF blocks before PHP starts. They complement each other: the WAF for filtering, the plugin for 2FA and limiting login attempts.
Inspection adds a small amount of time to each request, usually imperceptible next to application time. A very large ruleset or inspection of big request bodies can become visible; exclude file uploads and high-volume endpoints from inspection once you have checked them.
Yes, because SQL injection, directory traversal and unsafe deserialisation hit a JSON API just as well. Tune the rules for your format: exclude the HTML and XSS rules if the API never returns HTML, and add schema validation on the request body.
A production server starts getting attacked within minutes of receiving a public IP address, however small the project is. This guide ranks the controls by impact, from SSH access to incident response, with the Romanian rules that apply along the way. Every topic has its own page with a short answer, examples and ready-to-use configuration.