In short
A web application firewall (WAF) is a security layer that inspects HTTP requests to a website or API and stops attacks such as SQL injection, XSS, file inclusion, brute force and malicious bot traffic before they reach the application. CybUp sets up cloud WAFs such as Cloudflare, ModSecurity or Coraza with OWASP CRS, and FortiWeb-type appliances, and clears false positives before switching to blocking mode.
What is a WAF and how is it different from a network firewall?
A WAF is a firewall that works at the application layer. A network firewall asks “can this IP connect to this port?”; a WAF looks at what is inside the request: URL parameters, form fields, cookies, headers, the JSON body. An SQL statement typed into a search box or a script hidden in a comment field is only visible at this layer.
That is why a WAF complements firewall installation rather than replacing it. Any company that puts a web application on the internet needs both layers: the network firewall closes the ports you do not need, and the WAF checks whoever comes through the one door you leave open.
Which attacks does a WAF protect against?
A WAF is aimed mainly at the most common classes of attack on web applications. The reference list is OWASP’s OWASP Top 10:2025, which includes categories such as broken access control, security misconfiguration, software supply chain failures, cryptographic failures and injection.
For some of these categories a WAF blocks attacks outright; for others it makes the attacker’s job harder. To be honest, no WAF can fully close a flaw in the application’s own authorisation logic, such as one customer being able to see another customer’s orders. Think of a WAF as a layer in front of secure code, not a substitute for it.
- SQL injection, command injection and template injection attempts
- Cross-site scripting (XSS) and malicious script injection
- Local and remote file inclusion, directory traversal
- Brute-force and credential stuffing attempts against login pages
- Malicious bots, scrapers and scanning tools
- Application-layer request floods (L7 DDoS) and rate limit abuse
“The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.”
Cloud, software or appliance: which type of WAF suits you?
A cloud WAF is the quickest to deploy. A service such as Cloudflare sits in front of your traffic via DNS, so protection starts without touching your server. Cloudflare WAF’s managed rulesets include Cloudflare’s own managed ruleset and its implementation of the OWASP Core Ruleset; which ruleset comes with which plan can change, so we choose against the current documentation. The step most often forgotten with a cloud WAF is making the origin server accept traffic only from Cloudflare’s IP ranges. Skip it, and an attacker who finds the server’s real IP can bypass the WAF entirely.
A software WAF combines the ModSecurity or Coraza engine, running in front of Nginx or Apache, with the OWASP CRS rule set. Traffic stays on your own infrastructure and you have full control over the rules. It suits business applications hosted on your own servers and companies that care about data residency.
A hardware or virtual appliance WAF (products such as FortiWeb) offers central management, machine learning-based application profiling and reporting for busy enterprise environments with many applications. If your application runs on Azure or AWS, the provider’s own WAF services are also an option; we set those up in your subscription as part of our Azure and AWS configuration work.
How do you set up and configure a WAF?
A proper WAF setup does not start in blocking mode. First we get to know the application: which pages exist, which forms accept file uploads, where the admin panel is, which paths the API uses, which headers the mobile app sends. The WAF then goes live in detection (log-only) mode and watches real traffic for a while.
False positives that show up in this period, meaning legitimate requests mistaken for attacks, are examined one by one. OWASP CRS manages this trade-off with paranoia levels: level 1 is baseline protection that needs the least tuning, while higher levels are stricter but produce more false positives and call for rule exclusions. The right level depends on how sensitive the application is.
Once the false positives are cleared, the WAF is switched to blocking mode. Endpoints such as login, password reset and search get their own rate limits, and the admin panel is restricted by country or IP. Finally the WAF logs are connected to monitoring, so that blocked attacks and any wrongful blocks are visible.
“A higher paranoia level makes it harder for an attacker to go undetected. Yet this comes at the cost of more false positives: more false alarms.”
Example scenario: an e-commerce site in the run-up to a big sale
Say you run an e-commerce site on your own server and a major discount campaign is coming up. Over the last few weeks the login page has been getting hundreds of failed attempts a minute, product pages are being scraped non-stop by automated tools, and the logs show requests with SQL statements in the search parameter.
In a case like this the cloud WAF goes in first and the origin server is opened only to traffic from the WAF. Rate limits go on the login and basket endpoints, known bad bot signatures are blocked, and injection rules are applied to search and filter parameters. Legitimate automated traffic, such as the payment provider’s callback URLs, goes on the exception list; otherwise orders will not be confirmed. Before the campaign starts, the rules run in detection mode for a few days and then switch to blocking.
What needs doing after the WAF is in place?
A WAF is not something you install and forget. Every new feature in your application can bring new false positives, and behaviour can change when rule sets are updated. The logs need regular review, rule sets need to stay current, and major releases should be tested in detection mode first.
A WAF also buys time while vulnerabilities are being fixed. When a critical flaw is published in a plugin you use, a temporary rule can block requests that target it until the patch arrives. To see vulnerabilities in the infrastructure itself, we recommend periodic vulnerability scanning. If you are thinking of having your website rebuilt, our custom website development service builds security in from the design stage.
What you receive
- Application inventory: domains, subdomains, API and admin endpoints
- Installation and configuration of the chosen WAF type (cloud, software or appliance)
- Origin server locked down to accept WAF traffic only
- False positive tuning log and a list of rule exclusions
- Rate limiting, bot and admin panel access rules
- Log monitoring set-up and a short operating guide
How we work
- 1
Free review
We look at where your site and applications are hosted, your traffic profile and your current protection, recommend the right type of WAF and send a written quote.
- 2
Learning the application
Pages, forms, API paths, and payment and integration callbacks are listed; flows that will need exceptions are identified up front.
- 3
Go-live in detection mode
The WAF watches traffic without blocking it, and false positives are collected from real user traffic.
- 4
Tuning and blocking
False positives are resolved with rule exclusions, rate limits are added and the WAF is switched to blocking mode.
- 5
Monitoring and maintenance
Logs are connected to monitoring, and settings are reviewed after rule updates and application changes.
Frequently asked questions
Will a WAF slow my website down?
A correctly configured WAF adds latency your users will not notice. Because cloud WAFs usually work alongside caching, they can even improve page load times. With a software WAF we assess server resources before installation.
Will legitimate users get blocked by mistake?
This is the most delicate part of the job. That is why we run the WAF in detection mode first, clear out false positives and only then switch to blocking. If a block happens in production, we find the request in the logs and add the exception quickly.
Does my WordPress site need a WAF?
Plugin vulnerabilities are the most common way into WordPress sites, so a WAF makes a real difference. It still does not replace plugin and core updates; you need both.
Cloudflare WAF or ModSecurity: which should we use?
If you want fast deployment, DDoS protection and a solution that does not touch the server, a cloud WAF makes sense. If you want traffic to stay on your own infrastructure with full control over the rules, ModSecurity or Coraza with OWASP CRS is the better fit. In some environments we use the two in layers.
Does a WAF stop DDoS attacks too?
It handles most application-layer request floods with rate limits and bot rules. High-volume network-layer attacks that saturate your line have to be scrubbed on the provider side; cloud WAF services usually include this.
Does it protect our APIs and mobile app backend?
Yes, but API traffic is different from web page traffic. We write separate rules and rate limits for JSON bodies, authentication headers and client behaviour.
How long does a WAF setup take?
A basic cloud WAF can go live the same day. The detection-mode monitoring and tuning period takes anywhere from a few days to a few weeks, depending on how complex the application is.
How is it priced?
It depends on the number of domains and applications, the type of WAF chosen and whether you want ongoing maintenance. We send a written quote after reviewing the scope; the review is free.