WAF & rate limiting

Two of the first things a request meets on managed.dev are a web application firewall and a rate limiter. They sit in front of every site on every plan, inspecting and throttling traffic before it ever reaches PHP. You don’t install or maintain either — they’re part of the runtime — but it helps to know what they stop and how the parts you can tune behave.

The web application firewall

The WAF is built on the Coraza engine running the OWASP Core Rule Set (CRS). It inspects each request — method, path, query string, headers, and body — and blocks ones that match known attack patterns:

• SQL injection and command injection
• Cross-site scripting (XSS) payloads
• Path traversal and local/remote file inclusion
• Protocol and request anomalies (malformed methods, smuggling attempts)
• Scanner and bad-bot fingerprints

The ruleset is tuned for WordPress. The block editor, the REST API, and admin flows generate request shapes that naive WAF rules flag as attacks; the platform ships WordPress-aware exclusions so legitimate Gutenberg saves and REST writes pass while real injection attempts are still caught. Because the WAF understands JSON request bodies, an injection hidden inside a JSON payload is inspected, not waved through.

Note

The WAF runs at the site runtime, in the same place your application is served, so it sees the exact request your code would. Edge-level IP reputation (CrowdSec) runs even earlier — see Security → Blocks for how the two layers are attributed separately.

Modes

The firewall runs in one of two modes per site:

• Block — matched requests are rejected with a 403 and an audit entry. This is the protective default.
• Detect — matched requests are logged but allowed through. Useful when onboarding a site with unusual traffic, so you can see what would be blocked before enforcing.

coraza_mode is admin-controlled

The firewall mode (coraza_mode) is a platform-managed setting, not a per-site toggle you flip yourself. If a legitimate request is being blocked, don’t disable the WAF — open a support request with the block ID from Security → Blocks. The team adds a targeted exclusion (or switches the site to detect mode temporarily) rather than weakening the ruleset for everyone.

Rate limiting

Alongside the WAF, a token-bucket rate limiter caps how fast a single client can hammer a site. Each client earns tokens at a steady refill rate up to a burst ceiling; once the bucket is empty, further requests are throttled with a 429 until tokens refill. This absorbs short bursts while stopping brute-force login attempts, scraping, and crude denial-of-service floods.

The exact limits are tuned per plan and per site — higher-tier plans and busier sites get larger buckets. Default refill and burst values are plan-dependent; when a request is throttled it appears in Blocks attributed to the rate limiter, so you can tell a real spike from an attack.

How blocks surface

Everything either layer rejects is recorded as a block event, attributed to its source (coraza for the WAF, the rate limiter for throttles), and shown in the per-site Blocks view:

1. Open your site in the dashboard and go to the Security tab.

2. Select Blocks to see every blocked request over time, grouped by the control that stopped it.

3. Click a WAF block to see the matched rule and the request that triggered it. Use that detail when reporting a false positive.

Blocked requests are kept out of the normal Requests view so your traffic analytics aren’t skewed by attack noise.

Next steps

Security → BlocksRead and act on every WAF and rate-limit block, attributed by source.

Patchstack protectionVirtual patching for known plugin and theme CVEs, layered on top of the WAF.

Headers & allowlistsAdd IP allowlists and login lockout for an extra gate in front of the WAF.