🛡️ REST API Security: Why Bots Love Your Endpoints (And How to Make Them Pay)

Unlike scraping a website (which requires spinning up a browser, parsing JavaScript, navigating complex DOMs), REST API calls are just HTTP requests returning structured JSON. A bot can fire off hundreds of requests per second without any rendering overhead. This is why REST API attacks scale exponentially—the attacker's infrastructure cost stays minimal while they maximize attack volume.

WordPress REST API lives at /wp-json/wp/v2/. Most APIs follow REST conventions. Bots don't need to scout your infrastructure; they know exactly where to look. They can enumerate users, posts, and plugin information with automated scripts that run across millions of sites simultaneously. The endpoint path is the same for every target.

This is the killer feature attackers love. REST APIs don't require session state, cookies, or CAPTCHA challenges. In XML-RPC specifically, you can use system.multicall() to send 50-100 login attempts in a single HTTP request. Your per-request rate limiting becomes useless. Attackers make 1 connection and get 100 tries.

JSON is trivial to parse. Bots don't waste cycles parsing messy HTML. They get exactly what they need: user lists, post metadata, plugin info—all neatly structured and ready to extract. No AI parsing required. Simple regex and JSON libraries handle everything.

Web Login Form: CAPTCHA protection, rate limiting per session, cookie tracking, JavaScript validation

XML-RPC Endpoint: None of that. Completely stateless. Every request is independent. No session tracking. No CAPTCHA. And it supports batching—multiple authentication attempts in a single call.

The Result: XML-RPC brute-force attacks are devastatingly efficient. The attack surface is massive, the defenses are minimal, and most sites don't even know they're under attack until credentials are compromised.

This is the smoking gun. Most of these IPs aren't random VPN users. They're cloud infrastructure:

Wordfence-style temporary bans seem reasonable in theory: block an IP for 4 days, then automatically unblock. But this model doesn't account for attacker economics.

With a 4-day temp ban: An attacker just sets a timer and retries. The blocking cost is minimal. They run dozens of attacks in parallel, knowing that a few will eventually get unblocked. They can wait. The attacker wins.

Every failed attempt now costs them real money:

• Cloud VM cost — AWS charges ~$0.01-0.10/hour. Each blocked IP = a whole VM they have to throw away. No reuse. No waiting for an unblock.
• Provisioning friction — New instances take minutes to spin up and configure. This kills their attack speed.
• Infrastructure burnout — If they're cycling through 300 IPs in 48 hours, they're burning through cloud credits or proxy subscriptions at an unsustainable rate.
• Exponential cost scaling — The more you block, the more expensive their attack becomes. Eventually, the math breaks: cost per potential breach exceeds the attacker's ROI.

The attacker can't wait it out. They have to keep buying new infrastructure. And that gets expensive fast.

Hundreds of different IPs hitting the same endpoint isn't a failure of your defenses—it's proof your defenses are working. Here's the attacker's framework:

They're not targeting *you* specifically. They're running mass automation across millions of sites simultaneously. The moment one IP gets blocked, their script just rotates to the next one in their cloud provider bundle.

But here's the catch: They only have so many IPs in that bundle before they run out of credits or have to buy more. And that makes their attack economically unsustainable.

Here's where permanent blocking becomes a reconnaissance tool.

When you see 50+ failed login attempts from AWS IP ranges within 24 hours, you're not just blocking individual IPs—you're mapping attacker infrastructure. You can start flagging:

• Datacenter CIDR ranges — Block entire AWS subnets if they show persistent attack patterns
• Proxy service signatures — Recognize which VPN/proxy services attackers prefer and filter them
• Geographic anomalies — Flag IPs from regions that never legitimately access your site
• Timing patterns — Identify the time windows when attacks spike (usually off-hours to avoid detection)

The attacker's infrastructure becomes visible. Once you see it, you can make blocking decisions that scale beyond individual IPs. You're not reacting to attacks; you're predicting them.

Permanent IP blocking is powerful, but it's one layer. Real security is layered:

The goal isn't to make attacks impossible—it's to make them expensive enough that attackers move to easier targets. And with 300+ sites running simultaneous attacks, they're looking for sites with weak defenses. Be the hard target.

The data you're seeing is from one website. You have 7 sites running similar blocking. That means:

7 websites × 300+ blocked IPs each = 2,100+ attackers forced to rotate infrastructure in 48 hours.

Each blocked IP is one less attacker on your collective network. Each rotation costs them money. Each failed credential attempt validates that your defense is working. You're not just protecting one site—you're mapping and blocking botnet infrastructure at scale.

Attackers moving on to your competitors because your sites are too expensive to target? That's victory.

REST APIs are targeted because they're efficient. Bots love them because there's no friction—no session state, no CAPTCHA, no browser rendering, no per-request rate limiting at the UI level.

Permanent IP blocking flips the economics. Every failed attempt forces the attacker to spend money on new infrastructure. Cloud provisioning takes time. VPN rotation has limits. At scale, this friction becomes a dealbreaker.

The XML-RPC honeypot prevents credential breaches before they happen. Attackers never get to test stolen passwords because they're blocked before authentication. No breach means no data theft, no ransomware, no admin compromise.

Hundreds of different IPs in 48 hours isn't a sign of failure—it's proof the blocking is working. You've made attacks expensive enough that they're cycling through infrastructure as fast as they can provision it.

And that means your permanent IP blocking strategy is doing exactly what it's designed to do: protecting your sites by making attacks uneconomical.