Events and exceptions

Every block and every detection becomes an event. It is how you understand what the WAF decided and why — and it is where the exception comes from, the narrow fix for a false positive.

Events

An event records a request the WAF blocked or detected. One request may list more than one rule in the same event.

Field	What it shows
Date and time	When the request arrived
Domain	Which hostname received it
Client IP	Source address
Method	GET, POST and other methods
Path	The path, without the query string
Category	The attack family evaluated
Rule	The identifier of the rule that matched
Action	Blocked, detected or limited
Mode	Detection or prevention at that moment
Anomaly score	The sum the request reached
Request identifier	The same one the end user can report
Policy revision	Which configuration decided
Rule set version	Which OWASP rule set version was applied

The event does not store sensitive content: Authorization, cookies, bodies, query strings and tokens stay out. What you see is enough to decide, without becoming a credential archive.

Event retention is 30 days. Aggregated metrics are kept for 12 months.

Interpreting events

To read a block, follow this order:

1. Which rule matched. The OWASP rule identifier says what was recognized. Rules in the 942 range are SQL injection, 941 is XSS, 930 is LFI, 932 is command injection.
2. Which path. The same parameter may be legitimate on /api/search and not on /login.
3. Mode and score. In prevention, the score shows how far past the threshold the request went. In detection, it shows what would have happened.
4. Whether a custom rule was involved. If one of your rules blocked it, the event points to your rule, not to the OWASP rule set.

An example reading: a POST on /api/search blocked by rule 942100 (SQL injection) in prevention, with score 5 and no custom rule on the path. The conclusion is that the OWASP rule set saw an SQL-like payload in the body or in the parameters. If the form is free-text search, the next step is to repeat the same query and look at the event it generates.

Metrics

Metrics show allowed, blocked and limited requests, plus traffic volume, per domain. They are aggregated: they may arrive a few minutes after the event.

Metric	Use
Allowed requests	Confirm that normal traffic passes
Blocked requests	Measure attack and measure the effect of a policy change
Limited requests	Calibrate rate limiting
Traffic	Capacity and trend per domain

A delayed metric is not a wrong metric. To decide about a specific block, use the event, which is point-in-time.

False positives

A false positive is legitimate traffic stopped by a rule that recognized an attack. The signals are recognizable:

• the client reports an intermittent error on a specific form;
• the event points to the same rule and the same path, with the same parameter;
• the content is free text, documentation or a field that accepts markup;
• the blocking started after a paranoia level or rule set version change.

Before creating an exception, confirm the request really is legitimate. An exception is a narrow open door, but it is a door: that rule stops being evaluated on that path.

Exceptions

The exception is created from the blocked event, through the Create exception button. It is narrow by design:

Field	Options
Ignored rule	A single OWASP rule, by identifier
Path	Exact or by prefix
Methods	Optional, to restrict to some methods
Domain	One domain
Parameter	Optional, one ARGS, cookie or header by name
Reason	Required
Validity	Optional, with expiry

Example: ignore rule 942100 only on /api/search, with the reason "free-text search field with quotes" and a 90-day validity.

Usage rules:

• Never turn off a whole category. If the 942 family is annoying on one path, the exception is for the rule and the path, not for the family.
• Prefer the smallest scope that solves it. Rule and path before rule and domain; exact path before prefix.
• Set an expiry when the cause is temporary. An exception with a validity returns to evaluating on its own.
• Every exception is audited. Who created it, when, with which reason — and the same holds for removal.

A body exemption is not a rule exception. When the problem is body size on an upload endpoint, the fix is the body inspection exemption on the domain policy, not a rule exception: an exception ignores one OWASP rule on a path, while the exemption removes only the request body from inspection.

Next steps

• Policies — the paranoia level that generates the false positives.
• Troubleshooting — the codes the end user sees.
• Security — auditing and roles.