When someone says "my hosting has a firewall," they are almost always talking about one of two very different things without realizing it. One is the network firewall, which has been around forever and decides which ports are open. The other is a WAF, a web application firewall, which reads the content of every request hitting your site and decides whether it looks like an attack. They are different layers solving different problems, and confusing them leaves you believing you are protected when you are not.
The traditional firewall and its limits
A network firewall works at the level of ports and addresses. Its job is to say "MySQL port 3306 is not open to the world, only to the server itself" or "this IP that tried to connect two hundred times in a minute is now blocked." It is essential and every serious host has one.
The problem is that this firewall does not understand what a website is. To it, someone visiting your contact form and someone sending that same form a string of text designed to steal your database are exactly the same thing: legitimate traffic arriving on port 443. Both come through the right door with the right protocol. The network firewall lets both through, and it is right to do so. That is not its job.
What a WAF does differently
A WAF sits in front of your application and reads the content of every request: the URL, the parameters, the cookies, whatever was submitted in the form, the headers. It then compares that against a set of rules describing what known attacks look like, and blocks anything that matches.
A concrete example. If someone requests a URL like yoursite.com/product?id=5 OR 1=1--, the network firewall sees a normal request to your website. The WAF sees a classic SQL injection attempt and cuts it off before your code ever processes it. The same goes for text trying to smuggle JavaScript into a comment, requests fishing for system files, or forms receiving far more content than they should.
The attacks it actually stops
SQL injection. Still the most profitable attack there is, because the prize is the entire database: users, hashed passwords, orders, addresses. A WAF with current rules stops the vast majority of automated attempts.
Cross-site scripting. This means leaving JavaScript hidden somewhere on your site — a comment, a profile, a review — so it runs in other visitors browsers and steals their sessions. It is extremely common on sites that accept content from visitors.
Exploitation of freshly disclosed plugin flaws. This is where a WAF saves more sites than people imagine. When a vulnerability in a popular plugin is published, mass scanning starts within hours. You might take three days to update. A WAF with virtual rules can block that specific attack pattern from day one, even though your plugin is still unpatched. The industry calls this virtual patching, and it is a safety net while you do the right thing.
Brute force and scanning. Repeated attempts to guess passwords, and bots crawling your site looking for forgotten installer files, database dumps, or exposed admin panels.
What a WAF does not do
Let us be honest here, because there is a lot of marketing smoke. A WAF does not fix a badly built site. If your form stores passwords in plain text, the WAF does not solve that. If you left a backup folder reachable from the browser under a guessable name, the WAF will probably let it through because the request looks legitimate. And if someone gets your admin password because you reused it on a forum that suffered a breach, they will walk in the front door with valid credentials and no rule will stop them.
A WAF is one more layer. A good one, a useful one, often a decisive one, but a layer. You still need to update, use unique passwords, enable two-factor authentication, and keep backups that actually work.
False positives and how to live with them
The cost of running a WAF is that it occasionally blocks something legitimate. The classic cases: an editor writing an article about programming who pastes a snippet of SQL, a form submitting a very long text, or a plugin making requests in an unusual format.
The fix is never to switch the whole WAF off. It is to look at the block log, identify which rule fired, and create a specific exception for that rule on that URL. Any decent WAF shows you that log and lets you make the exception in two clicks. If yours will not tell you why it blocked something, it is a bad WAF.
Where the WAF lives and why that matters
There are three possible places and they are not equivalent. The first is a plugin inside your site: easiest to install, but weakest, because the attack already reached your server and already started PHP to process it. It burns your own resources defending you.
The second is at the server level, built into the software answering requests. This is considerably better: it blocks before your site even hears about it, without spending your resources, and it protects everything hosted there, not just WordPress.
The third is a cloud WAF sitting in front of your hosting, filtering traffic before it arrives. It is the most powerful option, especially against volume attacks, but it means routing all your traffic through a third party and usually carries a separate monthly cost.
For most sites the sensible combination is a server-level WAF included in the plan, plus the usual good practices. Only when the site earns real money or attracts targeted attacks does adding a cloud layer make sense.
What to ask before you sign up
When evaluating a host, do not settle for reading "firewall included" in the feature table. Ask three specific things: whether the firewall is network or application level, how often the rules are updated, and whether you can see the log of what it blocked and create exceptions yourself. Those answers tell you far more than any shield icon on the pricing page.
In BanaHosting case, protection comes in several layers from the server itself: application-level firewall with self-updating rules, denial-of-service mitigation, and malware scanning across the account files. It is not a plugin you install that eats your own resources — it works earlier, in the infrastructure, which is exactly where you want it working.