# Get started with the WAF

> Put a proxied name in log-only mode, review what the WAF would block, fix false positives and then switch to active protection.

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.

1. **Switch to log-only mode.** Nothing is blocked; every request the WAF would block is recorded as a security event with action `log`.

**Dashboard**

   Open the domain, go to **Security → Firewall** and, under **Protection**, choose **Mode → Monitor only**. Click **Save changes**, check the preview and confirm.
**CLI**

   ```sh
   openwaf-cloud ctl zones set example.com mode=log --reason "WAF in log-only mode while we tune it"
   ```
**API**

   ```sh
   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"}'
   ```
**MCP**

   Ask your assistant to put the zone in log-only mode. It calls `update_settings` with `{"zone": "example.com", "settings": {"mode": "log"}, "reason": "…"}`, shows you the diff and confirms with `confirm=true` and the `expected_version` it got.

2. **Pick the application and the level.** Set **Application** to your stack (`wordpress` matters: it enables the WordPress shield and stops OpenWAF from blocking `/wp-admin` and `/wp-login.php`). Keep **WAF sensitivity** at medium unless you have a reason to change it. See [Modes and levels](https://developers.openwaf.dev/waf/modes-and-levels/).
3. **Browse and test the site** for a few days: sign in, submit forms, use the checkout and the API.
4. **Review the events.** In **Analytics → Traffic**, filter by action `log`. Each event names the rule that matched (`rule_id`). See [Security events](https://developers.openwaf.dev/analytics/security-events/).
5. **Fix false positives** with a [WAF exception](https://developers.openwaf.dev/waf/waf-exceptions/) for that rule on that path, instead of lowering the level for the whole site.
6. **Switch to active mode** (`mode=active`, **Protect** in the dashboard) when the events show only real attacks.


> **Note: Log-only applies to the WAF and the shields**
>
> In log-only mode, OWASP CRS, OpenWAF's rules and the stack shields only record. IP and country rules, threat feeds, rate limits and the access gate keep applying. See [How a request is processed](https://developers.openwaf.dev/waf/request-processing/).


## Next steps

- Limit logins, one-time codes and APIs with [rate limiting rules](https://developers.openwaf.dev/waf/rate-limiting/#per-path-rules).
- Protect `/wp-admin` or `/admin` with the [access gate](https://developers.openwaf.dev/waf/access-gate/).
- Give one name its own WAF level with [per-name settings](https://developers.openwaf.dev/rules/per-name-settings/).