Filtering rules: blocking traffic without blocking customers
Every rule that blocks an attacker can also block a customer. Deploying rules straight into blocking mode is how sites break quietly.
What a web application firewall is for
It inspects requests before they reach the application and blocks those matching patterns associated with attacks. It is a filter in front of the software, not a fix inside it, and that distinction determines what it can reasonably be expected to do.
It buys time against known attack shapes. It does not make insecure code secure, and treating it as if it did is how organisations postpone the actual repair indefinitely.
Why default rule sets cause trouble
Generic rule sets are written to catch attacks against software in general. Your application is specific. A rule that blocks a suspicious-looking string will also block the customer whose surname, address or free-text comment happens to contain it.
- Form fields with free text are the most common source of false positives.
- File uploads often trip content inspection rules.
- APIs send payload shapes that generic rules were not written for.
- Content management back ends legitimately do things rules treat as suspicious.
- Non-Latin characters in names and addresses trigger encoding rules.
A safe way to introduce rules
- Run in detection mode first, for weeks, logging what would have been blocked.
- Read the log and identify legitimate traffic among the matches.
- Tune or disable the rules producing false positives, and record why.
- Switch to blocking gradually, starting with the rules that never matched real traffic.
- Keep watching after the switch: seasonal traffic differs from what you sampled.
- Have a documented way to disable it fast, and make sure more than one person knows it.
Rate limiting
Often more useful than pattern matching, and much less likely to break legitimate use. Limiting how often a single source can attempt a login or hit an expensive endpoint blunts a whole class of attacks without needing to recognise them.
What it does not replace
Keeping software updated, removing what is not used, restricting who can administer, and fixing the vulnerability when one is found. A filter in front of an unpatched system is a delay, and delays expire.