The WAF protects every name of a zone that has a proxied DNS record (A, AAAA or CNAME with the proxy on). New zones start with the WAF in active mode at the medium level. If the site is already in production, the safest path is to watch first and block later.
Switch to log-only mode. Nothing is blocked; every request the WAF would block is recorded as a security event with action
log.Open the domain, go to Security → Firewall and, under Protection, choose Mode → Monitor only. Click Save changes, check the preview and confirm.
openwaf-cloud ctl zones set example.com mode=log --reason "WAF in log-only mode while we tune it"curl -sS -X PATCH "https://dash.openwaf.dev/v1/orgs/$ORG/zones/example.com/edge" \ -H "Authorization: Bearer $OPENWAF_TOKEN" \ -H "X-Change-Reason: WAF in log-only mode while we tune it" \ -H "Content-Type: application/json" \ -d '{"mode": "log"}'Ask your assistant to put the zone in log-only mode. It calls
update_settingswith{"zone": "example.com", "settings": {"mode": "log"}, "reason": "…"}, shows you the diff and confirms withconfirm=trueand theexpected_versionit got.Pick the application and the level. Set Application to your stack (
wordpressmatters: it enables the WordPress shield and stops OpenWAF from blocking/wp-adminand/wp-login.php). Keep WAF sensitivity at medium unless you have a reason to change it. See Modes and levels.Browse and test the site for a few days: sign in, submit forms, use the checkout and the API.
Review the events. In Analytics → Traffic, filter by action
log. Each event names the rule that matched (rule_id). See Security events.Fix false positives with a WAF exception for that rule on that path, instead of lowering the level for the whole site.
Switch to active mode (
mode=active, Protect in the dashboard) when the events show only real attacks.
Next steps
- Limit logins, one-time codes and APIs with rate limiting rules.
- Protect
/wp-adminor/adminwith the access gate. - Give one name its own WAF level with per-name settings.