Monitor mode
protects nothing.
Most web application firewalls are not blocking. One blocked a legitimate request, enforcement went off until somebody had time to tune it, and nobody ever did. The licence renews, the dashboard looks busy, the application is undefended.
A WAF in blocking mode,
and kept there.
A web application firewall inspects traffic to your applications and stops the requests that are trying to attack them. Buying one is straightforward. Having one that is actually enforcing is the part this service exists for.
It sits in front of your applications and filters what reaches them: injection attempts, cross-site scripting, the OWASP Top 10, credential stuffing, scraping and volumetric floods. It also buys you time on a vulnerability you cannot patch today, which is frequently its most valuable property — a virtual patch at the edge while the real fix goes through a release cycle.
What we run is the operating half. Deployment and traffic learning, then the tuning, then the move into blocking mode, then the exception handling every time the application changes and something legitimate starts matching a rule. That last part never stops, and it is the reason most in-house WAFs quietly end up in monitor-only.
- OWASP Top 10, injection, cross-site scripting and protocol abuse.
- Bot management, credential stuffing and scraping controls.
- Volumetric and application-layer denial-of-service protection.
- Virtual patching, so an unpatched flaw is covered at the edge.
- Tuned to your application, then re-tuned when it changes.
- Alerts read by the same 24/7 SOC that handles everything else.
Nobody turns a WAF off.
They turn it down.
It is almost never a decision. It is a Tuesday afternoon, a broken checkout, an angry commercial director, and the fastest way to make the problem stop.
The sequence is the same everywhere. The WAF goes in and works. Then a legitimate request — a long form post, an unusual character in a surname, a file upload, a third-party integration — matches a rule and a customer cannot complete something. The pressure to fix it is immediate and the pressure to keep enforcing is theoretical, so blocking goes off, or the rule set is loosened well beyond the one thing that broke.
That is a reasonable decision made under pressure by someone who has other work. The failure is that it is never revisited, because revisiting it means carefully reproducing an incident nobody wants to reproduce. Handling exactly that, calmly, with a scoped exception rather than a blanket loosening, is the difference between a managed WAF and a WAF with a support contract.
- Learn before enforcing
- Deployed in monitor mode first and tuned against your real traffic, so the move into blocking is a planned step rather than a gamble on a rule set.
- Exceptions, not exemptions
- When something legitimate matches, the exception is scoped to that path and that pattern. The rule stays on everywhere else, which is the bit that usually gets lost.
- Re-tuned when the app changes
- A release, a new endpoint, a new integration. Rule sets are revisited against the application as it is now, not as it was at onboarding.
- Virtual patching under pressure
- When a flaw is disclosed and your release cycle is three weeks, a rule at the edge closes it the same day. That is often the single most useful thing a WAF does.
If your WAF is in monitor-only today, say so when we talk. It is the most common starting position and it is a fixable one — it is not a reason to be embarrassed.
Monitor, tune, block,
and keep it blocking.
Four weeks from deployment to enforcing is typical. The fourth step is the one that runs forever, and it is the one you are paying for.
-
01
Deploy and learn
In front of the application in monitor mode, learning real traffic patterns. Nothing is blocked yet, and nothing breaks, which is how you find out what would have.
-
02
Tune against reality
Every match reviewed against your actual traffic. Legitimate patterns are scoped out precisely rather than by switching whole rule families off.
-
03
Move into blocking
Enforcing, in a planned window, with a rollback position and somebody watching. This is the step that does not happen on its own.
-
04
Handle the exceptions
A release adds an endpoint, an integration sends something unusual, a surname has an apostrophe in it. Scoped, documented, and protection stays on everywhere else.
-
05
Report what it stopped
What was blocked, what was tuned, and what the traffic says about who is interested in your application. Alerts that matter go to the SOC, not to a mailbox.
Web application firewalls, answered.
What is a web application firewall?
A filter that sits in front of a web application and inspects requests before they reach it, blocking the ones attempting to attack it — injection, cross-site scripting, credential stuffing and the rest of the OWASP Top 10. A network firewall cannot see any of that.
Do we need one if we already have a firewall?
Yes. A network firewall decides whether traffic may reach your server. A WAF reads what that traffic is actually asking the application to do. Almost all web attacks arrive over ports a network firewall is meant to allow.
What is WAF as a service?
The WAF runs as a hosted service in front of your applications rather than as an appliance you own and maintain. No hardware, no patching of the WAF itself, and protection that scales with traffic instead of with what you bought.
Will it break our application?
It is deployed in monitor mode first and tuned against your real traffic before anything is enforced, so the matches that would have broken something are found and scoped out before blocking is switched on.
What happens when it blocks a real customer?
We scope an exception to that specific path and pattern and leave the rule enforcing everywhere else. The common failure is a blanket loosening under pressure, which quietly removes far more protection than the one thing that broke.
Can you run a WAF we already own?
In most cases yes. Where you already hold the licensing we will operate what you have rather than sell you something new, and we will say plainly if the platform you own cannot do what you need.
Does it protect against DDoS?
It handles application-layer floods and volumetric traffic, which is what takes most web applications down. It is not a substitute for upstream network-level protection on a very large attack, and we will tell you where that line sits for your setup.
How is it priced?
Per application, based on traffic volume and how complex the rule set needs to be. A simple brochure site and a transactional platform are not the same job, so pricing follows a look at what you are protecting.
Tell us if yours is in
monitor-only today.
It is the most common starting position and it is a fixable one. Getting a WAF back into blocking mode without breaking anything is a known piece of work, not a rescue project.