Your Security Stack Is Blocking You From Your Own Site

Opening your page builder shouldn’t trigger a security ban on your own site. But when the editor fires 54 API requests in 47 seconds, your intrusion detection doesn’t know it’s you — it sees a crawler. Here’s why IP whitelisting is the wrong fix, and what to do instead.

Full transparency: Links marked with (*) are affiliate links. Yes, we might earn a commission if you buy. No, that doesn’t mean we’re shilling garbage. We recommend what we’d actually use ourselves. Read our full policy.

Question: What if your security tool can’t tell the difference between you and an attacker — and blocks you instead?

The Assumption Everyone Makes

Page builders talk to the REST API. That’s normal. What’s less normal is opening an editor and watching 54 API requests fire in 47 seconds — not because that’s the only way to build the feature, but because bulk-fetching post data on init is the path of least resistance. Other builders solve the same problem with fewer roundtrips. Etch doesn’t, and your security stack has no way to know the difference between a legitimate editor session and a crawler doing exactly the same thing. So it bans you.

The fix isn’t complicated. But it shouldn’t have been necessary.

What Actually Happens

The Etch builder preloads post data via the WordPress REST API on editor init. Opening the editor fires 50+ GET requests to /wp-json/etch-api/ within 47 seconds — all authenticated, all returning 200, all completely legitimate. To CrowdSec, that burst profile is indistinguishable from a crawler. The crowdsecurity/http-crawl-non_statics scenario triggers, your IP gets banned, and the editor breaks. A secondary plugin health check then triggers crowdsecurity/http-admin-interface-probing as a cascade.

The fix everyone reaches for is “whitelist my IP.” That fails immediately on a dynamic connection: your ISP reassigns the address and you’re blocked again within a session.

Why This Matters More Than You Think

The instinct to whitelist by IP is the wrong mental model. The signal that triggered the ban isn’t who is making requests — it’s where those requests go. The etch-api namespace is a plugin-specific, non-standard REST route. No crawler, no scanner, no legitimate bot has any reason to touch it. Suppressing crawl detection for that path doesn’t weaken your coverage. It eliminates a false positive that has zero defensive value.

Blanket IP whitelists solve the wrong problem and require maintenance. Path-scoped expression whitelists solve the right problem once.

The Fix

Inspect the alert first to confirm the pattern:

cscli alerts list --scenario crowdsecurity/http-crawl-non_statics --limit 5
cscli alerts inspect <alert-id>

Confirm the target_uri values are all within /wp-json/etch-api/. Then create the whitelist:

/etc/crowdsec/parsers/s02-enrich/whitelist-etch-builder.yaml

name: crowdsecurity/whitelist-etch-builder
description: "Suppress false positives from Etch builder API burst"
whitelist:
  reason: "Etch builder bulk-loads post data via etch-api on editor init"
  expression:
    - "evt.Meta.http_path startsWith '/wp-json/etch-api/'"

Reload CrowdSec:

sudo systemctl reload crowdsec

The http-admin-interface-probing alert that follows is a cascade — WordPress fires a plugin status check after the editor loads. Suppress the initial burst and the cascade disappears with it.

Verifying the Fix

Check the whitelist parser is loaded:

cscli parsers list | grep whitelist-etch

Then pull a real nginx log line and run it through the parser chain:

grep "etch-api" /var/log/nginx/access.log | tail -1

Pass that line to cscli explain:

cscli explain --log 'YOUR_LOG_LINE' --type nginx --verbose

In the s02-enrich stage you should see whitelist-etch-builder with whitelisted: true. If the counter stays at zero or the stage is skipped entirely, the expression isn’t matching — double-check the path in your YAML.

As a final real-world confirmation, open the Etch editor and immediately run:

cscli decisions list --ip YOUR_IP

No ban decision means the whitelist is doing its job.

Strategic Opposition Principle

Identify what you’re actually protecting before deciding what to block. A whitelist scoped to the wrong dimension — IP instead of path — solves nothing durably. The right suppression is surgical: narrow enough to be defensible, wide enough to stay out of your own way.