Why Cloudflare, Imunify360 etc Hurt Users on Bad Connections and Old Devices

The core conflict

These systems are designed around an assumed “model user”: someone on a fast, stable connection, with a modern browser, on a device capable of running current JavaScript, from an IP address that doesn’t change. Anyone outside that model gets treated as a threat by default. The people worst served by this are, predictably, those with the least reliable infrastructure.

Specific problems for users on slow, expensive, or unreliable connections

  • Challenge screens are JavaScript-heavy. Cloudflare’s and Imunify360’s bot challenges rely on JavaScript execution, cookies, and often a round-trip to verify. On a 2G connection or a congested mobile network, this can take many seconds, time out, or fail outright. The user is locked out of content they could otherwise read.
  • Every layer adds weight and latency. Each proxy, firewall, and verification step is another thing that has to load before the user sees anything. On a good connection, this is invisible. On a bad one it’s the difference between a page loading and not loading.
  • Data cost. Challenge screens, verification scripts, and retries all consume data. For users on metered or expensive mobile data, this is a real cost for content they may never even reach.
  • Failure modes are silent and confusing. When a challenge fails on a bad connection, the user often just sees a blank page or a spinner. There’s no error message telling them what went wrong or what to do about it. They assume the site is broken and leave.

Specific problems for users on old devices

  • Old browsers fail modern challenge scripts. Devices running older Android, older iOS, or outdated browser versions may not support the JavaScript features these systems rely on. The challenge never completes, and the user is permanently locked out.
  • Limited RAM and slow CPUs struggle with heavy JS. Even when the challenge technically runs, it may take so long or consume so many resources that the browser tab crashes or the user gives up.
  • No graceful degradation. These systems generally don’t offer a fallback for devices that can’t run the challenge. It’s pass the test or get nothing.

The structural inequity

  • The systems protect the provider, not the user. Cloudflare and Imunify360 exist primarily to reduce risk and cost for the hosting provider or site owner. The user experience is a secondary concern, and for users on constrained connections, it’s often a negative one.
  • “Best practice” assumes the opposite of your users’ reality. Most hosting and performance advice is written for users on fast connections with modern devices. Following it blindly can actively harm users on slow connections — the very users you’re trying to serve.
  • The security model penalises the wrong people. A person on a flaky 3G connection in a region with rotating IPs looks, structurally, exactly like a bot: inconsistent IP, failed challenge attempts, retries, and unusual request patterns. The system can’t tell the difference between “suspicious” and “poor infrastructure”.

Design principles that follow from this

  • Minimise moving parts between the user and the content. Every proxy, firewall, and challenge screen is a point of failure on a bad connection.
  • Prefer static output where possible. Plain HTML/CSS/JS has no dynamic endpoints to trigger WAF rules, no PHP to scrutinise, and nothing for bot protection to evaluate. It’s cheaper, faster, and immune to most of this class of problem.
  • Spend your “quality” budget on what the user actually feels — page weight, image compression, whether the site works on 3G — rather than on hosting tiers or security products.
  • Test on the connections and devices your users actually have, not on the ones you happen to own.
  • Treat added layers as costs, not features. Each one needs to justify itself against the user experience it degrades.

The wider pattern

This is part of a broader phenomenon where automation is clashing with other priorities — and the need for automation is winning. Bot detection, fraud prevention, and security systems are tuned for the median case and treat outliers as threats. The outliers are disproportionately people in regions with poor infrastructure, on old devices, and on expensive data. It’s a quiet, structural inequity that rarely gets named, because the people most affected are the least likely to be in the rooms where these systems are designed.

Deeper…

Reference Case: The redacted False Positive

What happened

A WordPress page on shared hosting was repeatedly blocked when saving via the editor. The hosting provider’s logs showed the request was intercepted by Imunify360’s WAF, not because of the endpoint being hit (the initial suspicion), but because the page content itself contained the string /etc[forward slash]shadow.

The log entry

text

"Access denied with code 403 (phase 2). [file "/etc/modsecurity.d/002_i360_basic.conf"] [line "15"] [id "77142167"] [msg "IM360 WAF: Block URI containing malicious URLs||RSV:8.61||T:APACHE||MVN:ARGS:content||SC:/home/nimno/domains/nimno.net/public_html/wp-json||"] [severity "CRITICAL"] [tag "service_im360"]"
"action":{"intercepted":true,"phase":2,"message":"Matched phrase \"/etc[forward slash]shadow\" at ARGS:content."}

The key line is the last one: Matched phrase "/etc[forward slash]shadow" at ARGS:content. The rule saw the string in the request body and blocked it, with no evaluation of what the content actually was.

The content that triggered it

“On the boot partition of the SD Card, the hashes of the passwords are stored in /etc[forward slash]shadow, usually towards the end of the file, e.g.”

This is legitimate technical documentation about Raspberry Pi boot partitions and Linux password storage. It is exactly the kind of content that a site about Linux, embedded systems, or security is supposed to contain.

Why this is a false positive, not a bug

The rule is not malfunctioning. /etc[forward slash]shadow is a real attack target, and blocking requests containing that string is a defensible heuristic if your only goal is to stop attacks. The problem is that the rule has no concept of context. It cannot distinguish between:

  • an attacker probing for /etc[forward slash]shadow via injection, and
  • a technical article explaining how /etc[forward slash]shadow works.

Both look identical at the byte level. Because the system cannot tell them apart, it defaults to blocking — the safe choice for the provider, the hostile choice for the user.

Why this matters disproportionately for some users

Technical writing is full of strings that security tools flag: /etc[forward slash]shadow, /etc/passwd, chmod, shell examples, SQL snippets, regex patterns, sample payloads for teaching purposes. The more useful the content is to the people it’s written for, the more likely it is to trip a rule.

For users on slow or unreliable connections, in regions where the site may be their only reliable access to this kind of material, a block that a European admin would barely notice can be the difference between the page loading and not.

The pattern

This is the same structural problem as the bot-challenge screens discussed elsewhere in this wiki:

  • The system is optimised for the median case and treats legitimate outliers as threats.
  • The user has no way to signal “I am not the thing you are worried about” other than by changing their behaviour — in this case, not writing the article.
  • The metric the system optimises for (attacks blocked) does not include the harm caused by legitimate users blocked alongside them.

The designers are not malicious. They are optimising for a metric that excludes the collateral damage. That is the part that is structurally broken.

Practical workarounds

  • Whitelist the editing IP in Imunify360 (only works if the IP is static).
  • Ask the host to disable or tune the specific rule (id 77142167).
  • Move the site to a VPS where you control the WAF configuration.
  • Move to static output, where there is no request body to scan.
  • Rewrite the content to avoid the literal string (works, but is a capitulation — the content is correct and the rule is wrong).

The wider point

This is not an argument against security tooling. It is an argument for security tooling that can distinguish between a threat and a description of a threat. Until it can, the cost of the current approach is borne by the people with the least ability to work around it.