A web application firewall, or WAF, becomes much more useful when an attack is actually happening. You don’t want to spend ten minutes debating a rule while someone is hammering your login page. The policy needs to react quickly and block the traffic that looks dangerous without taking the whole application offline.
Start With a Targeted Block
During an active attack, the first move is usually to tighten a WAF policy around the traffic causing trouble. If requests from a particular IP address are flooding the application, you can block that source. If the attack is hitting one URL, a rule can focus on that path instead of affecting the entire website.
And that’s important. A broad block feels reassuring, but it can also stop genuine customers from reaching the site. A narrow rule gives you room to respond without creating another problem.
Temporary Rules Have Their Place
Temporary policies are especially useful during an incident. You can block a suspicious pattern for a short period while the security team investigates what is happening.
• A specific IP range under pressure from repeated malicious requests, although don’t assume every request from that range is bad.
• A URL receiving strange input repeatedly, which is often where a focused rule makes more sense than a site-wide block.
• Rate limits for an endpoint that suddenly receives far more requests than normal, particularly login and search pages.
Adjust Rules as the Attack Changes
Attackers don’t always stick with one method. They may change request patterns after a block is introduced, so watching WAF logs matters just as much as creating the first rule. You need to see what is being blocked and what is still getting through.
Because of that, WAF policies should be adjusted during the incident rather than treated as something you configure once and forget. You might raise the sensitivity of a managed rule, add a custom condition, or tighten rate limits around the affected endpoint.
Watch for False Positives
Blocking malicious traffic is only half the job. A rule that catches an attack but also blocks real users isn’t exactly a clean victory.
So keep an eye on legitimate requests while the policy is active. If customers suddenly report failed logins or broken forms, check whether the new rule is responsible. Sometimes a small exception is enough.
Use WAF Policies as an Incident Response Tool
A WAF can act like a fast control layer while deeper investigation continues in the background. Security teams can use it to reduce harmful traffic immediately, then work on fixing the application or closing the underlying vulnerability.
• Emergency blocking, where speed matters more than elegance for a few minutes.
• Tighter inspection on suspicious requests, with normal traffic left alone as much as possible.
• A temporary exception for trusted traffic, if an aggressive rule starts catching legitimate users.
Remove Temporary Policies Carefully
Once the attack slows down, don’t simply leave every emergency rule sitting there forever. Old rules can become confusing, overlap with newer policies, or block traffic that becomes legitimate later.
Review what was added during the incident. Keep rules that address a real weakness, but remove temporary controls that no longer have a purpose. Then update the permanent WAF policy based on what the attack actually revealed.