How to introduce filtering without breaking anything

Three positions, and the value is entirely in not skipping the middle one.

Off. Nothing is inspected. This is the starting state, and the state to return to if something is badly wrong.

Monitor. Requests are inspected and matches are recorded, and nothing is refused. Everything you learn about your own traffic is learned here, at no cost to anybody.

Block. Matching requests are refused rather than forwarded, and they continue to be recorded.

Going straight from the first to the third is the mistake this whole section exists to prevent. It means discovering your false positives from customers, which is the slowest and most expensive way available to learn what a rule set does to your particular site.

Not for finding attacks. For finding the requests your own site generates that happen to resemble one.

That distinction matters because it changes what you look at. Attacks in the record are reassuring and tell you little. The useful entries are the ones you recognise: a search containing text that looks like an injection attempt, a partner integration posting a payload that trips a rule, a support form where customers paste error messages full of code, your own monitoring hitting an endpoint faster than a person would.

Read the record asking one question of every entry: would refusing this have been correct? Everything that answers no is work to do before enforcing, and it is invisible from every other vantage point.

Run it long enough to include an unusual day. A week of ordinary traffic tells you about ordinary traffic, and the entries that matter often arrive on the day somebody runs a campaign, a partner does a bulk import, or somebody in another timezone starts their working week.

Both failure modes are real and they are not symmetrical, which decides everything above.

A missed attack is visible eventually. Something happens, you investigate, you respond, and the record helps. A refused customer produces nothing at all: no error report, no support ticket, no entry that reads as a problem. They leave, and your log shows a request that was successfully blocked.

That asymmetry means unmeasured filtering drifts in one direction only. It never drifts toward being too permissive, because that failure announces itself; it drifts toward confident, invisible harm, because that one does not.

Every specific exception should carry a date on which somebody looks at it again.

Exceptions accumulate. Each is added for a good reason during an incident or a launch, and each outlives the circumstance that justified it. After a year nobody remembers which are still needed, and the safe assumption becomes leaving all of them, which is how a filtering layer quietly becomes a list of holes nobody can audit.

The rule that works is simple: anything narrow enough to be called an exception is narrow enough to expire. Broad, permanent decisions belong in configuration, where they are visible; narrow ones belong on a review date.

There is no scale to slide and no aggressiveness level to raise, and that shapes how tuning works here.

The configuration is the three positions above. What you adjust instead is the specific: which rules apply, which requests are exempted, and which limits are set where. That makes tuning slower to think about and far easier to explain, because every change is a statement about something concrete rather than a step on a scale whose meaning nobody can define.

The practical consequence is that a tuning change can always be described in a sentence. If it cannot, it is probably not a tuning change.

It records requests the firewall flagged, with enough context to decide whether the decision was right.

It is not a traffic overview, not a view of volumetric attack figures, and not a general analytics surface. Those are separate questions answered by separate things, and a log attempting all three would be worse at the one job that makes monitor mode work. Reading it as a measure of how much traffic you receive will mislead you in both directions.

The part that gets skipped, because by then the pressure is off.

Emergency measures are taken quickly and correctly under pressure: a broad block, a tight limit, an exemption to unstick something. Every one of them was right for that hour and almost none of them is right permanently. The review afterwards is what separates a system that learned from one that accumulated.

Write down what was changed while it was happening, because nobody reconstructs it afterwards. Then decide, for each item, whether it becomes permanent, becomes an exception with a date, or is removed.

The pages below work through each stage: what monitor mode shows and how to read it, turning enforcement on in stages rather than at once, finding and measuring false positives without switching everything off, exceptions and their expiry dates, what the activity log contains and what it does not, handling an incident and unwinding it afterwards, and tuning when there are no dials to turn.

Bridge WAF has three modes, off, monitor, and block, and nothing between them. Flagged requests appear in a security activity log in batches with sub-second latency, which is what makes reading the monitor record practical while the traffic that produced it is still current. Rate limiting is applied per domain, covered on rate limiting. See what the platform offers at Bridge CDN.