Policies

The policy is the set of decisions the WAF applies to a domain.

The domain policy

Each domain points to one policy, which defines the mode the WAF runs in, how sensitively it evaluates the OWASP rules, the inspected body limit, and which custom rules and rate limits apply there.

Changes take effect for the domain traffic as soon as they are saved, and every save produces a new revision — the revision shows up in events so you know which configuration decided each block.

Operating modes

Mode	What it does	When to use it
Detection (DETECTION)	Evaluates the OWASP rules and logs what would match as an attack, without blocking on them	First contact, false positive tuning, legacy application
Prevention (PREVENTION)	Blocks when the request anomaly score reaches the threshold	Production, after validating real traffic

The difference between modes applies only to the OWASP rules. These controls act in both modes:

• custom rules with a block action;
• the platform baseline;
• rate limiting.

In other words: in detection you are already protected against what you configured explicitly; what stays under observation is the OWASP rule set judgement.

OWASP CRS

The rule set is the OWASP Core Rule Set 4.25.2 (LTS), applied by the Coraza 3.8.1 engine.

Parameter	Default	Range	Effect
OWASP rule set	On	on or off	Whether to evaluate the community rules
Paranoia level	1	1 to 4	How strict the rule set is
Inbound anomaly threshold	5	configurable	Score from which the request is blocked in prevention

Paranoia level is the most important adjustment. At level 1 the rule set stops clear attacks with few false positives. Each level above widens coverage and raises the chance of blocking legitimate traffic: go up one level at a time and read the events before going further.

Anomaly score is the sum of the points of the rules that matched the request. Each rule carries a weight; when the sum reaches the threshold, the request is blocked in prevention. In the event, the score field shows that value.

What is inspected in the body

Content type	Inspected
application/x-www-form-urlencoded	Yes
multipart/form-data	Yes
application/json and +json subtypes	Yes
XML	Yes
Other types	Depends on the OWASP list

Inspected body size. The WAF inspects request bodies up to a limit. Each policy defaults to 64 KiB, and the maximum a policy can declare is 1 MiB. Inspection cost grows linearly with body size, so above that the request costs more processing than the service allows. A request with a body larger than the policy limit is rejected with 413. If you need to accept larger uploads, use the body inspection exemption on the endpoint — do not raise the policy limit.

Content types outside the OWASP list are blocked at paranoia level 1 by rule 920420. That usually shows up with text/plain and with vendor +json. The right path is an exception for the type on that path, not turning off the rule family: see Events and exceptions.

Body inspection exemption for uploads

Body exemption for uploads. On delimited upload endpoints, you can exempt only the request body from inspection: headers, path and URL parameters remain inspected. The exemption is scoped by path (exact or prefix), with optional methods and domain, a required reason, optional expiry and a required maximum body size (up to 100 MiB). While it is in force, the WAF: rejects with 413 the request whose Content-Length exceeds the declared maximum size; rejects with 411 the request that arrives with Transfer-Encoding (chunked/streaming upload), because without a declared size there is no way to guarantee the ceiling — send Content-Length; records the exemption in the audit log. Exceeding the policy limit does not release anything automatically: without an exemption, a body above the limit is rejected. Managing the exemption requires the WAF Editor or WAF Admin role, and it counts against the same quota as exceptions.

Tuning the policy

1. Start in detection, with the OWASP rule set on and paranoia level 1.
2. Let real traffic run for a few days and read the events.
3. For each block that is a false positive, create a narrow exception straight from the event.
4. Only then switch to prevention.
5. If you need more coverage, raise the paranoia level by one step and read the events again.

Prevention is not all or nothing

Custom rules and rate limiting work in detection. You can start by blocking what is unambiguous — a country, an admin path, a method — and leave the OWASP rule set under observation until you trust the result.

Next steps

• Custom rules — blocking and allowing by condition.
• Events and exceptions — reading the policy decision and handling false positives.
• API — managing the policy through the API.