REST API Security: Why Bots Love Your Endpoints<
🛡️ REST API Security: Why Bots Love Your Endpoints (And How to Make Them Pay)
Why REST APIs Are a Bot's Best Friend
REST APIs are not designed with security theater in mind. They're designed to be simple, predictable, and easy to consume programmatically. That's their strength—and the attacker's dream.
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.
The XML-RPC Amplification Problem
XML-RPC is a WordPress legacy endpoint built for mobile apps and external tools. It's also a brute-force engine—and it's the path of least resistance for attackers.
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.
What We're Actually Seeing
(48 hours, 1 site)
Attacks
Attacks
Automated Pattern
This is the smoking gun. Most of these IPs aren't random VPN users. They're cloud infrastructure:
34.x, 35.x, 18.x, 44.x, 52.x, 54.x ranges. Either compromised accounts or cheap throwaway instances rented by attackers.
35.x, 34.x ranges. Same story—rented infrastructure used for mass scanning and credential attacks.
DigitalOcean, Linode, datacenter proxies, residential proxy services. All rotating through attack bundles.
Why Permanent Blocking Beats Temporary Bans
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.
The XML-RPC Honeypot: Catching Attacks Before Credential Breaches
This is the critical insight most sites miss: By blocking XML-RPC attacks immediately, you're not just annoying bots—you're preventing them from ever using stolen credentials on your site.
The Traditional Attack Flow:
Your Blocked Flow:
The attacker never gets to test their stolen credentials. They never even make it to the authentication layer. They hit the block and get a new IP, but the damage is already prevented.
This is why permanent blocking is so effective: you're not just preventing brute force. You're preventing credential stuffing attacks entirely. Someone with a list of 10,000 stolen WordPress admin passwords can't use them against you because they get blocked before they can even try.
Why They Keep Coming Back (And Why That's Good News)
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:
1. Target list: millions of WordPress sites (scraped from plugin fingerprinting)
2. Endpoint: /wp-json/wp/v2/users or /xmlrpc.php (same on every site)
3. Payload: credential stuffing (stolen passwords) or weak password dictionaries
4. Execution: Try IP #1 → blocked → try IP #2 → blocked → try IP #3 → repeat
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.
The Detection Signature: Seeing the Infrastructure
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.
Defense in Depth: Layered Protection
Permanent IP blocking is powerful, but it's one layer. Real security is layered:
If you don't use it, remove it entirely. Via .htaccess, firewall rules, or plugin. Don't give attackers the endpoint.
Not per request—per authentication attempt. Catch the batching exploit. One request = one limit, not 100.
Even if an attacker has a stolen password list, 2FA stops them cold. Make admin accounts unhackable.
If you expose REST endpoints, require authentication. Lock down user enumeration endpoints immediately.
Watch for rapid IP rotation, geographic spikes, and cloud provider attacks. Build detection rules.
Every failed attempt costs the attacker. Make attacks expensive. Force them to burn through infrastructure budgets.
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 Bigger Picture: 7 Websites, Unified Defense
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.
The Verdict
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.
