Custom rules

Custom rules let you decide about traffic using your knowledge of the application, without depending on the generic OWASP rules. There is no script, no expression and no regular expression: each rule is a condition picked from a list and an action.

Custom rules

A rule has three parts:

Part	What it defines
Condition	What the request must have to match
Action	What the WAF does when the condition matches
Priority	The evaluation order among your rules

A single rule can combine more than one condition. The rule only matches when all conditions hold at the same time.

Conditions

Condition	How it works	Example
IP	Compares the client address with an address	203.0.113.10
CIDR	Compares the client address with a range, IPv4 or IPv6	203.0.113.0/24
COUNTRY	Compares the client country; accepts several countries	BR, US
URL_PATH	Compares the path, exact or by prefix	/admin as a prefix
HTTP_METHOD	Compares the request method	POST
HTTP_HEADER	Compares a header, by equality, contains or prefix	X-Api-Version contains 2.
USER_AGENT	Compares the client agent, by equality, contains or prefix	curl as contains

The country comes from the DB-IP Lite database, updated monthly. The required attribution is: IP geolocation by DB-IP, CC BY 4.0 license. Geolocation is an approximation — do not use country as the only access control for sensitive data.

Some headers cannot be used as a condition, because the WAF needs them to route and deliver the request: Authorization, Cookie, Host and the X-Forwarded-* family. To handle authorization or session data, use the OWASP rule set plus a narrow exception, not a custom rule.

Actions

Action	Returned code	What happens
BLOCK	403	The request is refused and logged as an event
ALLOW	—	Evaluation of the following custom rules stops for that request
MONITOR	—	The request passes and the case is logged as an event
RATE_LIMIT	429	The request counts against the limit set in the rule

ALLOW is the most confusing point: it stops only the following custom rules. OWASP inspection and rate limiting still apply to that request.

RATE_LIMIT on a rule limits a specific path, on top of the domain-wide limit. Excess requests get 429 and appear in the events. See Rate limiting.

Evaluation order

platform controls → rate limiting → custom rules (by priority) → OWASP rule set

1. Platform controls — the NNumbers baseline, the same for everyone.
2. Rate limiting — the domain limit and the per-path limits.
3. Custom rules — in priority order: the lower number is evaluated first.
4. OWASP rule set — the anomaly evaluation that decides blocking in prevention.

If two of your rules match the same request, the lower number decides. That is why allow rules need a low number when they must win over block rules.

Examples

Goal	Condition	Action	Priority
Block admin panel access from outside Brazil	URL_PATH prefix /admin and COUNTRY not BR	BLOCK	10
Allow a partner using a legacy integration on /api/legacy	IP equal to the partner address and URL_PATH prefix /api/legacy	ALLOW	20
Observe PUT attempts on the API before blocking	HTTP_METHOD PUT and URL_PATH prefix /api	MONITOR	30
Limit bulk download	URL_PATH prefix /export	RATE_LIMIT	40
Block known scanning agents	USER_AGENT contains masscan	BLOCK	50

The wrong action is not fixed by the OWASP rule set

If an ALLOW lets through something that should be blocked, the fix is in the rule priority or condition — not in the paranoia level.

Next steps

• Rate limiting — limits per client and per path.
• Events and exceptions — confirming the effect of each rule.
• Policies — the mode and paranoia level that apply along with the rules.