Skip to main content
.com domains from $2.99 — free WHOIS privacy on every name

Architecture note · Intermediate · 20 min reading

How to understand website firewalls — Where a WAF Sits, and What It Costs Per Request

You want to know what is inspecting your traffic, in what order, and whether it is the reason one particular form stopped working last Tuesday.

The short answer

A web application firewall inspects HTTP requests before your application code runs, matching them against rule sets for known attack shapes — injection strings, path traversal, probes for specific published vulnerabilities — and rejecting what matches.

Its position is the whole point. A request rejected before PHP starts costs you a pattern match; the same request allowed through costs a PHP worker, a database connection and whatever your application then does with it. That is also why a WAF block looks unlike an application error: the response never touched your code, so nothing appears in your application log.

By the HostingFast team · Reviewed 24 August 2026

Intermediate

Assumed level

Quick

Reading time

5

Steps to done

24/7

Engineers on call

Twenty minutes of reading rather than configuration. The point is to know what is already running in front of your site, what it can and cannot do, and how to diagnose it when it gets something wrong.

Imunify runs at server level on every account here — ImunifyAV+ on Sprint and Turbo, Imunify360 with its WAF on Nitro and the business tiers — with DDoS filtering absorbed further out at the network edge.

The request path, in order

A request arriving at your site passes several checkpoints. First the network edge, where DDoS filtering absorbs volumetric floods before they reach any server. Then the server itself, where Imunify360's WAF matches the request against its rule set. Then, if you run one, a CDN or application-level filter. Then your application's own validation. Then your code.

Each layer that rejects early saves everything downstream. It is the same economics as caching: the cheapest work is the work that never happens, and a request refused at the edge costs you nothing at all.

What the inspection actually costs

Rule matching against headers, query string and body happens in microseconds at server level. Set against the alternative — booting PHP, opening a database connection, running your application's logic on a hostile input — it is not close. A WAF is one of the few security controls that usually makes the machine faster under attack rather than slower.

Where it can cost something noticeable is body inspection on large uploads, since the payload has to be examined before it is passed on. If you accept big file uploads and see them slow down, that is worth mentioning to support rather than diagnosing as a network problem.

The rule set is the product

A firewall is only as current as its rules. New vulnerabilities are published constantly, and the value of a maintained rule set is that it can block exploitation of a component you have not yet updated. That is virtual patching: it does not fix your code, it refuses the requests that would exploit it, which buys you the days between an advisory and your own update window.

Which means the refresh cadence matters more than the feature list. A stale rule set is decoration, and a rule set someone else maintains and updates continuously is the actual thing you are buying.

False positives, diagnosed properly

Occasionally a legitimate request looks like an attack: a contact form message containing SQL-flavoured text, a developer pasting a code snippet into a support form, a URL with an unusual query string. The signature is distinctive — a 403 or 406 arrives, and your application log has no record of the request at all, because it never reached your code.

The remedy is an exception scoped to one rule on one path, taken from the block report, which names the rule that fired. What it is not is switching the engine off, which trades one broken form for every rule you were benefiting from. If you cannot find the rule ID, support can read the block log with you.

The network filtering that soaks up attacks before they reach a site

What runs in front of your account here

Imunify protection runs at server level on every account, with Imunify360 and its WAF on the Nitro tier and both business plans, and DDoS filtering absorbed further out at the network edge.

LiteSpeed in front of NVMe means the traffic that does get through is largely answered from cache, so your PHP workers stay free for the requests that need them.

  • The request path drawn out layer by layer
  • Inspection cost compared with the alternative
  • A WAF block distinguished from an application 403
  • Support who will read the block log with you

Why HostingFast

Standard on every plan

Position explained first

Where each layer sits in the request path, which is what determines both what it can see and what it saves you.

Costs compared honestly

Pattern matching against booting PHP for a hostile request, including the one case where inspection is noticeable.

Virtual patching, defined

What the rule set buys you between a published advisory and your own update window, stated without overclaiming.

False positives given a signature

A 403 with nothing in the application log — the specific fingerprint that tells you which layer refused the request.

Exceptions scoped narrowly

One rule, one path, taken from the block report, rather than the global switch that undoes everything else.

Already running, not an upsell

Imunify at server level and DDoS filtering at the edge are on the platform, so this is a page about using what you have.

Quick Start

From order to online

  1. 1

    Establish which layers you actually run

    Imunify at server level on every account here, with Imunify360's WAF on Nitro and the business tiers, DDoS filtering at the network edge, plus anything you have added at a CDN. Knowing the list is what makes a block diagnosable.

  2. 2

    Learn the fingerprint of a WAF block

    A 403 or 406 returned to the client with no matching entry in your application's log. The request was refused before your code ran, which is why nothing in the application knows it happened.

  3. 3

    Find the rule, not the switch

    The block report names the rule that fired. That identifier is what you except. Disabling the engine to fix one form is trading a broken contact page for every other rule you were quietly benefiting from.

  4. 4

    Scope the exception as narrowly as it will go

    One rule, one path, one method where the interface allows it. A global exception for a rule that fired once on one URL is far wider than the problem you were solving.

  5. 5

    Read the reporting monthly, for the shape

    The blocked-attack count is mostly background noise, and its level is not interesting. A sharp deviation from that level is: it usually means somebody has taken a specific interest in your site.

Built In

Loaded onto every plan

  • Imunify protection at server level on every account
  • Imunify360 with its WAF on the Nitro tier and both business plans
  • DDoS filtering absorbed out at the network edge
  • LiteSpeed caching in the server, keeping PHP workers free
  • Free SSL on every plan, renewed automatically before it can expire
  • Daily backups with self-service restores from the panel
  • Full SSH access with Git and Composer on every shared plan
  • cPanel IP Blocker for the specific addresses a WAF is not meant to handle
  • Money-back cover: 30 days on hosting plans, 7 on reseller
  • Human support on duty every hour of every day

Frequently Asked

What people ask us most often

How do I tell a WAF block from an application 403?

Look in your application's log. A WAF refuses the request before your code runs, so there is no entry: the visitor saw a 403 or 406 and your application never knew a request arrived. An application-level 403 is the opposite — it is your own code deciding, and it will normally have logged the decision. That single check tells you which layer to go and look at, and saves you searching the wrong one.

Does a firewall add latency for legitimate visitors?

Very little. Matching headers, query string and body against a rule set happens in microseconds at server level, and the comparison is not against zero — it is against the cost of letting a hostile request boot PHP and open a database connection. Under attack, a WAF usually makes the machine faster. The one case where inspection is noticeable is large file uploads, where the body has to be examined before it passes on.

Does a firewall mean I can stop updating plugins?

No. Virtual patching buys you time, not immunity: a maintained rule set can refuse the requests that would exploit a known vulnerability, which covers the gap between an advisory being published and your own update window. It does not fix the vulnerable code, and it cannot know about a flaw nobody has written a rule for. Treat it as the thing that makes a patching schedule survivable rather than optional.

Where does virtual patching fit against a newly published CVE?

In the window between disclosure and your deployment. When a vulnerability in a widely used component is published, exploitation attempts follow within hours, while your own update may be a day or a week away depending on testing. A rule that matches the exploit pattern refuses those attempts in the meantime. Once you have applied the real update, the rule is redundant for you but still protects everyone who has not.

Keep reading

Changing hosts? Run through our checklist first.

A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.

You'll get the checklist email, then occasional pointers on keeping a site running fast. Unsubscribe the moment you want out — the privacy policy covers the rest.

Filtering that happens before your code runs.

Imunify at server level, DDoS filtering at the network edge, LiteSpeed keeping PHP workers free, and engineers who will read the block log with you.

View VPS Hosting plans