WAF and web application firewall: protecting business websites and applications
WAF and web application firewall: what it blocks, what it misses, cloud WAF, appliance or server module, OWASP CRS rules and rolling it out without breaking the site.
The short answer: a WAF (web application firewall) sits in front of a website or web application and inspects every HTTP and HTTPS request to block known attacks: SQL injection, cross-site scripting, file inclusion, exploitation of a published flaw. It complements the network firewall, updates and two-factor authentication without replacing them. It is deployed as a cloud service, as a dedicated appliance or virtual machine, or on the web server, and it is brought into service in detection mode before blocking, so as not to cut off legitimate customers.
This guide explains what a WAF stops, what it cannot see, how to choose its form and how to roll it out properly. It draws on documentation from OWASP, the OWASP CRS project, Fortinet, Cloudflare and Microsoft.
Why the network firewall is not enough for a website
The business firewall decides who can reach which service. For a public website, an online store or a customer portal, it must let web traffic through to the server: that is the whole point. Yet application attacks hide precisely in that allowed traffic. A request that slips an SQL command into a search field goes through port 443 like any other visitor.
OWASP defines the WAF as an application firewall for HTTP applications: it applies a set of rules to the HTTP conversation to detect common attacks such as cross-site scripting and SQL injection. OWASP notes that a WAF protects servers, and that it can be considered a reverse proxy.
The applications concerned in a business are often more numerous than expected: brochure site with a contact form, online store, extranet or customer portal, ERP or CRM reachable from outside, API used by a mobile app, webmail portal.
What a WAF blocks, and what it cannot see
| A WAF is effective against | A WAF struggles with |
|---|---|
| Injections (SQL, commands, LDAP) | Poorly designed access control in the application |
| Cross-site scripting (XSS) | Abusable business logic (discount, quantity, skipped step) |
| File inclusion, directory traversal | A legitimate account used with a stolen password |
| Exploitation of a published flaw, before the update | A flaw in a browser-side library |
| Aggressive bots, repeated login attempts | Sensitive data exposed by a misconfiguration |
The OWASP Top 10 2025, the reference list of application risks, puts broken access control (A01) and security misconfiguration (A02) at the top; injection comes in at A05. A WAF acts mainly on part of these categories. The rest is handled in the application itself, through updates, configuration review and penetration testing.
The big operational benefit of a WAF is virtual patching: when a flaw is published in exposed software, a WAF rule can block exploitation attempts while the update is prepared. Microsoft puts it this way in its documentation: a WAF can react faster by centrally patching a known vulnerability, instead of securing each application. That buys time, but it does not replace patch management, as our alert on the PHP “PHP2Shell” vulnerability showed.
The three forms of WAF
| Form | Examples | Suited to | Watch points |
|---|---|---|---|
| Cloud service in front of the site | Cloudflare WAF, Azure WAF with Azure Front Door or Application Gateway | Site or application hosted by a provider or in the cloud | Traffic goes through the provider; direct access to the origin server must be blocked |
| Dedicated appliance or virtual machine | FortiWeb, hardware or virtual machine | Applications hosted on your premises, data centre or private cloud | Operations, signature updates, high availability |
| Server module or plugin | ModSecurity or Coraza with OWASP CRS, WordPress security plugin | A single server or site | Uses server resources; protection limited to that server |
The cloud WAF service
The site stays with its host, but the domain name points to the provider’s service, which filters traffic before passing it on to the server. According to Cloudflare’s documentation, its WAF combines managed rules updated by the vendor, custom rules and rate limiting rules; the free plan includes custom rules, one rate limiting rule and a reduced managed ruleset, with the full managed rules reserved for paid plans. At Microsoft, Azure WAF is deployed with Azure Front Door and Azure Application Gateway, and in preview with Azure Content Delivery Network.
A key point: if the origin server can still be reached directly by its IP address, an attacker simply bypasses the WAF. Access to the server is therefore restricted to the provider’s addresses only.
The dedicated appliance or virtual machine
For an application hosted on your side, the WAF appliance sits in front of the web servers. The documentation for FortiWeb, Fortinet’s WAF, describes several operating modes: reverse proxy (the default mode, where traffic is addressed to a virtual server on the FortiWeb and then forwarded to the real server), transparent modes that require no address or DNS change, and offline protection, a passive mode mostly used for observation. FortiWeb adds FortiGuard signatures, machine-learning anomaly and bot detection, API protection (JSON, XML, GraphQL, OpenAPI validation) and an OWASP Top 10 compliance dashboard.
On a FortiGate, a web application firewall profile also exists, but it only works with proxy-based inspection, according to the FortiOS documentation. For an important exposed application, a dedicated WAF remains more complete.
The server module
ModSecurity and Coraza are WAF engines installed on the web server. They are used with the OWASP CRS (Core Rule Set), a set of generic attack detection rules covering SQL injection, XSS, file inclusion and command injection, among others. For a WordPress site, a security plugin provides similar filtering, as explained in our guide to securing a business WordPress website.
Which form to choose for your situation
| Your situation | Recommended form |
|---|---|
| WordPress brochure site with a hosting provider | Cloud service in front of the site, plus a security plugin |
| Online store or customer portal hosted in the cloud | Cloud service with full managed rules, rate limiting and retained logs |
| Business application or ERP hosted on premises and open to the outside | WAF appliance or virtual machine in front of the servers, as a reverse proxy |
| Application hosted on Microsoft Azure | Azure WAF with Application Gateway or Front Door |
| API used by a mobile app or a partner | WAF that validates the API schema (OpenAPI, JSON) and limits request rates |
Before choosing, ask a simple question: does the application really need to be open to the whole Internet? An ERP used only by employees can often be restricted to VPN or conditional access, in a zero trust approach. What is not exposed does not need filtering. Exposure also matters for compliance: a form or customer portal collects personal data, which Morocco’s Law 09-08 requires you to protect with appropriate security measures.
Rolling out a WAF without breaking the site
The main difficulty with a WAF is not installing it, it is tuning it. A WAF that is too strict blocks customers, a form or a sync job; one that is too permissive is useless. The OWASP CRS documentation describes four paranoia levels: level 1 very rarely raises a false alarm and is the recommended starting point; each higher level detects more attacks but produces more false positives. It considers moving to a high level in blocking mode without prior tuning very risky.
Our method, in order:
- Inventory the exposed applications: addresses, technologies, forms, APIs, admin accounts.
- Start in detection mode: the WAF logs what it would have blocked, without blocking anything.
- Analyse the logs over a period of normal use, including month-end and automated jobs.
- Handle false positives with targeted exclusions (one rule for a specific parameter or address), without disabling whole rule families.
- Switch to blocking mode, first on the clearest attacks, then more widely.
- Lock down the origin: only the WAF may reach the web server.
- Monitor: send WAF alerts to the monitoring platform or SIEM, and review the rules whenever the application changes.
OWASP points this out: customising a WAF can take significant effort, and it must be maintained as the application changes.
The most common mistakes
- Leaving the WAF in detection mode for months without reading the logs.
- Disabling entire rule sets at the first false positive.
- Forgetting to close direct access to the origin server.
- Believing the WAF removes the need to update the application and its server.
- Protecting the public site but forgetting the API, the extranet or the admin access.
- Leaving the application’s admin interface open to the whole Internet, without two-factor authentication.
How we support businesses
We start with the free initial audit: inventory of exposed sites and applications, technologies and versions, protections in place, admin access and logs. We then recommend the right form of WAF, cloud service, Fortinet appliance or Microsoft Azure service, bring it into service in detection mode, tune out false positives and move to blocking. ALLSAFE supplies the hardware and licences, with or without installation.
As part of our business cybersecurity in Morocco offering, WAF alerts feed into 24/7 monitoring, and a critical incident is handled in under 15 minutes. Request your free initial audit: we reply within 24 business hours.
Frequently asked questions
What is the difference between a regular firewall and a WAF?
The network firewall decides who can reach which service, by address, port and application; it lets web traffic through to a public site, since that site must be reachable. The WAF inspects the content of those allowed HTTP and HTTPS requests to spot an attack, for example SQL injection in a form field. The two complement each other.
Does a brochure website need a WAF?
A well-maintained brochure site, kept up to date and without sensitive forms, can make do with a cloud WAF service or a security plugin. As soon as there is a customer portal, an online store, an API or a business application exposed to the Internet, a configured and monitored WAF becomes an important protection.
Does a WAF protect against every vulnerability?
No. It mainly blocks attacks that can be recognised in the request, such as injections or the exploitation of a known flaw. It struggles with an access-control mistake specific to the application, poorly designed business logic or a stolen password. Updates, two-factor authentication and security testing remain essential.
Can a WAF block legitimate customers?
Yes, that is the main risk of a poorly tuned WAF: false positives. The OWASP CRS documentation recommends starting at the lowest sensitivity level, handling false positives with targeted exclusions and raising the level only after tuning. That is why we start in detection mode.
Where should the WAF sit: in the cloud or on premises?
It depends on where the application lives. For a site hosted by a provider or in the cloud, a cloud WAF service placed in front of the site is simplest. For an application hosted on your premises or in your data centre, a dedicated appliance or WAF virtual machine in front of the servers keeps the traffic under your control.
About the editorial team
ALLSAFE SOLUTIONS
Network, security and cloud engineers
Written by the engineering team at ALLSAFE SOLUTIONS, a managed IT provider founded in Casablanca by network, security and cloud engineers. Our articles draw on the projects we deliver for clients in Morocco and abroad.
LinkedIn
