You buy web hosting and read the phrase "advanced firewall" on the features page, and you assume your site is protected from being hacked. The problem is that this phrase covers two completely different things: a network firewall, which decides who comes in through which door, and a web application firewall, which reads what the visitor is actually carrying in their hand.
The short version: a web application firewall (WAF) is not a replacement for a network firewall or for updating your plugins, but it is the only layer that sees injection attacks as they happen. As for OWASP, its name appears on every marketing page, and people mix up three different things under it. We will separate them one by one.
Quick summary: WAF and OWASP in one table
| Criterion | Details |
|---|---|
| Definition | A service or program that inspects every HTTP/HTTPS request before it reaches your application and decides whether to pass, block or log it |
| Layer | Layer 7 (application) of the OSI model |
| What it inspects | The URL, headers, cookies, parameters and request body |
| OWASP Top 10 | A list that raises awareness of the most serious web application risks. It is not rules and not software. Latest edition: 2025 |
| OWASP CRS | An open-source set of attack-detection rules that runs inside the WAF. Latest version: 4.30.0 (October 2, 2026) |
| What it does best | Stopping injection attacks (SQL and XSS), exploitation of known plugin flaws, and bots |
| What it does not do | Fix application-logic bugs, or protect non-web services such as SSH and databases |
What is a web application firewall (WAF)?
A web application firewall stands between the visitor and your application and inspects every request before it reaches it. It works at layer 7 of the OSI model, which is why it can understand the content of the request and not only its source. In most cases it works as a reverse proxy in front of the server that runs your site, so it receives the request first and then passes it on or blocks it.
Every web request carries parts that can be inspected: the address, the method (GET or POST), the headers, the cookies, the query parameters and the body. Compare these two requests:
GET /products?id=5 HTTP/1.1
GET /products?id=5' OR '1'='1 HTTP/1.1The second request tries to trick the database into returning records that were not meant to be shown. A network firewall notices no difference between the two requests: both come in through the same port 443 from an ordinary IP address. A WAF sees the difference because it reads the request.
What is it trying to stop? SQL injection, cross-site scripting (XSS), command injection, path traversal, malicious file uploads, automated scanning tools and the exploitation of known plugin flaws. When you read about a WordPress site being hacked through an old plugin, this is exactly the kind of attack a WAF was designed to intercept.
The idea is not new. ModSecurity, the best-known open-source engine for this purpose, appeared in the early 2000s as a module for the Apache server, and later supported other servers. There is also a newer engine written in Go called Coraza that reads the same rules.
What does OWASP have to do with a firewall? Three things everyone mixes up
OWASP is a community-run nonprofit (the Open Worldwide Application Security Project) that publishes free references and tools on application security. Its name gets attached to three different things, and most marketing articles mix them up on purpose or by ignorance.
First: the OWASP Top 10 is an awareness list, not rules
It is a list of the ten most serious categories of web application risk, updated every three to four years. The latest edition is OWASP Top 10:2025, the eighth, which follows the 2021 edition. Two new categories entered it (software supply chain failures, and mishandling of exceptional conditions), security misconfiguration jumped to second place, and SSRF was folded into the broken access control category. OWASP describes the list as an awareness document, not a testable standard.
The practical question: how much of this list can a WAF actually stop? The answer is less than marketing pages say:
| Item (2025) | Category | WAF coverage | Why |
|---|---|---|---|
| A01 | Broken access control (includes SSRF) | Partial | It blocks path traversal, but it does not know who is allowed to see which record |
| A02 | Security misconfiguration | Partial | It can block access to exposed files such as .env, but it cannot fix a wrong setting |
| A03 | Software supply chain failures | Weak | It can temporarily plug a known plugin flaw, but it does not deal with a compromised component itself |
| A04 | Cryptographic failures | Not covered | A design and configuration problem inside the application |
| A05 | Injection (SQL, XSS and others) | Strong | This is its original strength and the target of most CRS rules |
| A06 | Insecure design | Not covered | A flaw in the application's logic, not in the shape of the request |
| A07 | Authentication failures | Partial | Rate limiting and bot blocking limit brute-force attempts |
| A08 | Software or data integrity failures | Weak | It detects only some malicious deserialization payloads |
| A09 | Security logging and alerting failures | Weak | Its logs are useful, but they do not replace the application's own logs |
| A10 | Mishandling of exceptional conditions | Weak | Its effect is limited unless it inspects responses and hides error messages |
Second: OWASP CRS is the rule set that actually runs inside the WAF
The Core Rule Set is a set of generic attack-detection rules written in ModSecurity's SecRules language, and it runs on compatible engines such as ModSecurity and Coraza. It is free and open source. The latest version when this was written is 4.30.0 (released on October 2, 2026). In the same series, version 4.25 is the first long-term support (LTS) release in the project's history (announced in March 2026), with 4.25.2 as the current LTS point release and security fixes promised until Q3 2027, while the old 3.3 branch has reached end of life.
The clever idea in CRS is that it does not block a request at the first rule that matches. Each rule adds points to the request's total (anomaly scoring), and when the total passes a set threshold (the default is 5 for inbound requests) the request is blocked. One suspicious word is not enough, so false blocking falls.
Then there are the paranoia levels, from 1 to 4. Level 1 is the default and suits most sites. Each raise of the level detects more attacks, but it necessarily increases false blocking, so levels 3 and 4 are for someone protecting sensitive data who is ready to spend weeks writing exceptions. And do not confuse the paranoia level with the score threshold: they are two independent settings.
To see what a rule looks like, here is a very simplified example in ModSecurity syntax (real CRS rules are much more complex and use generated regular expressions and specialized checks for injection patterns):
SecRule ARGS "@rx (?i:union\s+select)" \
"id:1001,phase:2,deny,status:403,msg:'SQL Injection attempt'"Third: what marketers call "OWASP protection"
When a provider writes "protected against the OWASP Top 10," it most likely runs a version of CRS (such as Cloudflare's OWASP Core Ruleset, Cloudflare's implementation of the OWASP ModSecurity Core Rule Set, which its docs say is based on version 3.3.0) or rules of its own. That mainly covers the injection categories, and it does not close every item on the list as the advert suggests. Always ask: which rule set? And in which mode, monitoring or blocking?
How does a WAF decide a request is malicious?
There are four methods, and most products combine more than one. Signatures (the negative model) block what looks like a known attack; they are fast, but obfuscation can fool them. An allow list (the positive model) permits only what is expected, such as an id parameter that accepts only numbers; it is more accurate, but expensive to maintain and it breaks with every site update. Scoring is the CRS approach explained above. And reputation and behavior rely on data about bad IP addresses and request rates, where a cloud WAF has the advantage because its provider sees the traffic of millions of sites, while a WAF installed on your own server sees only your site.
Cloudways' optional Cloudflare Enterprise add-on includes WAF and DDoS protection, enabled from the dashboard, starting at $4.99 per domain per month for 1 to 4 domains, with a 30-day free trial
☑️ Try Cloudways now
The difference between a WAF and network protection
The whole point is in one place: your site needs port 443 open to the world, or no visitor can reach it. A network firewall will leave that door open by its very job, and every web attack passes through it like any ordinary visitor. The door is open on purpose, and the question is what comes through it.
| Comparison | Network firewall | Web application firewall (WAF) |
|---|---|---|
| Layer | 3 and 4 (network and transport) | 7 (application) |
| Basis of the decision | IP address, port, protocol and connection state | The content of the HTTP request: the address, headers, cookies, parameters and body |
| Does it read HTTPS content? | No, it only sees that an encrypted connection exists | Yes, because it works after decryption at the termination point |
| It stops | Port scans, and access to services that were not meant to be public (SSH and databases) | SQL injection, XSS, path traversal, exploitation of plugin flaws and bots |
| It does not stop | Any attack that comes through the allowed port 443 | Attacks on non-web services such as SSH, FTP and databases |
| Examples | iptables, UFW and the server provider's firewall | ModSecurity with CRS, Cloudflare WAF and AWS WAF |
| Who manages it | The server provider or the system administrator | You, or the protection platform you subscribe to |
And there is the encryption difference. Most traffic today is HTTPS, and an ordinary network firewall does not open it, so it cannot tell whether a request is innocent or an injection. A WAF sits where the encryption layer is removed, whether at a cloud reverse proxy or at the web server itself.
As for flood (DDoS) attacks, their ground is different. They use up bandwidth before they reach any inspection rule, so serious protection from them comes from a wide distribution network that absorbs the attack, not from WAF rules. A sensible setup is layers: a distribution network that absorbs floods, then a network firewall that closes everything not needed, then a WAF that reads requests, then an updated application behind all of them. Removing any layer leaves a gap that the others do not cover.
Kinsta's docs list a fully managed WAF and Cloudflare-based DDoS protection on all of its plans
☑️ Discover Kinsta plans
Where do you actually put the WAF for a WordPress site?
A cloud WAF works as a reverse proxy: you route your domain's traffic through a network such as Cloudflare's network by changing DNS records, so requests are inspected before they touch your server. These are your real options, with frank notes:
| Option | Where it works | A frank note |
|---|---|---|
| Cloudflare (free plan) | Cloud, before the server | It runs the Free Managed Ruleset only. The OWASP Core Ruleset is not available on it |
| Cloudflare (Pro and above) | Cloud, before the server | The Cloudflare Managed Ruleset and the Cloudflare OWASP Core Ruleset are available. Cloudflare's docs warn that the OWASP ruleset is prone to false positives and adds only marginal benefit on top of the Managed Ruleset, so it needs monitoring and tuning. Check current prices before you buy |
| A security plugin (Wordfence or Jetpack) | Inside PHP on your server | The malicious request uses your server's resources before it is blocked. In Jetpack, automatically updated firewall rules need a paid plan (Security, Complete or Scan), and the free plugin offers brute force protection and manual IP rules |
| Managed hosting (Kinsta or Cloudways) | Cloud, from the hosting panel | At Kinsta it is part of every plan. At Cloudways you need to turn on the optional Cloudflare Enterprise add-on |
| ModSecurity or Coraza with CRS | On your server | Free, and you control everything, but tuning and exceptions are your responsibility |
For the last option you need a server you control, that is, a VPS or a dedicated server. And if your hosting runs on the cPanel panel, many providers run ModSecurity at the server level, but control over it often stays with the hosting administration, so ask what actually runs there before you assume.
And if your site is on a ready-made platform, the difference between website builders and traditional hosting shows up here: the ready-made platform handles protection for you and takes away the ability to tune it, and traditional hosting gives you the tuning and the responsibility for it.
False blocking: the price nobody mentions
Any new WAF will block innocent things. The best-known example on tech sites: you write an article with a snippet of SQL or a <script> tag to explain something, and saving is blocked in the WordPress dashboard because the request looks like an injection. That is not a fault; the firewall is working as designed. The fix is a specific exception for that path, not turning off the whole rule. And any fair assessment of a WAF has to count the first tuning time, not the price alone.
Virtual patching: a grace period, not a fix
When a flaw appears in a popular plugin, WAF providers release a rule within hours that blocks the exploit pattern, which is called virtual patching. It buys you days to update the plugin calmly. But it does not fix the flaw, and an attacker may find a request form the rule did not anticipate. Updating the plugin is still the real fix.
What a WAF cannot do, however expensive
It does not detect business-logic flaws: a user changing the order number in the link to see someone else's invoice is a perfectly well-formed request. It cannot tell a user who stole a valid password and logged in normally. It does not protect services outside the web. And any zero-day for which no rule has been written yet will pass through it. These are the limits of the whole type, not a defect in a particular product.
Practical steps to turn on a WAF without blocking your visitors
Jetpack adds a firewall with automatically updated rules (on its Security, Complete and Scan plans) alongside malware scanning
☑️ See Jetpack plans
Who needs to care about this, and who does not?
✅ A WAF is essential for you if:
- Your site is WordPress with many or old plugins
- You run a WooCommerce store or keep customer data
- You have login, search and comment forms open to everyone
- You expose an API to the public
- You see repeated injection or scanning attempts in your logs
❌ It may not be your priority if:
- Your site is static HTML pages with no forms and no database (though a distribution network is still useful against floods)
- Your ready-made platform handles protection completely
- You have not updated WordPress and its plugins for months: start with the updates before any firewall
The verdict: what to do after reading this
Our direct view: for most WordPress bloggers, the sensible choice is a cloud WAF in front of the site together with strict discipline about updates, not buying an expensive security bundle and then letting plugins go stale. Cloudflare's free plan is useful as a first layer, but do not think of it as complete "OWASP protection," because the OWASP Core Ruleset starts at Pro, and Cloudflare's own docs describe it as prone to false positives. If you are looking for new hosting, make a managed WAF one of your selection criteria and see our comparison of the best web hosting companies. And whoever wants more comfort should look at managed Kinsta hosting or Cloudways cloud hosting, where protection comes ready-made.
As for someone who runs a VPS and has the time and experience, CRS with ModSecurity or Coraza gives full control at no fee. Just count your time spent tuning exceptions, which is the real cost. In every case: a WAF covers injection well and covers the rest of the list partially or not at all, so do not build all of your security on it.
Cloudways: turn on Cloudflare Enterprise (WAF and DDoS) for each application whenever you like, from the same dashboard
☑️ Start with Cloudways
✅ Frequently asked questions about WAF and OWASP
❓ What is the difference between OWASP and OWASP CRS?
❓ Does a WAF replace a network firewall?
❓ Does a WAF protect me from every OWASP Top 10 flaw?
❓ Does Cloudflare's free plan include OWASP rules?
❓ What does Paranoia Level mean in CRS?
❓ Why does a WAF sometimes block my visitors, or me?
❓ Does a WAF slow down my site?
❓ Do I need a WAF for a small WordPress site?
❓ Is a WordPress security plugin enough as a firewall?
❓ Can I run OWASP CRS for free?
Kinsta: its docs list a fully managed WAF and DDoS protection on its hosting plans
☑️ Try Kinsta now
Did the explanation help? Share it with someone who runs a site, and if you have a question about tuning a WAF, write it in the comments.
