Archive.today CAPTCHA Causes Repeated Requests — Technical Evidence & Fixes
Archive.today CAPTCHA Causes Repeated Requests — Technical Evidence & Fixes
Direct inspection shows archive.today’s CAPTCHA page executes a short JavaScript loop that issues automated requests to a target blog roughly every 300 milliseconds. The pattern yields sustained, DDoS-level traffic while the CAPTCHA remains open.
What the code does (plain language)
The CAPTCHA page contains a small script that repeatedly asks the target site for search results. Because each request includes a randomized query, responses are not cached — the target server must generate or fetch a new result for each request. When many visitors have the CAPTCHA page open, the volume multiplies quickly.
Representative snippet (simplified)
fetch("https://gyrovague.com/?s=" + Math.random().toString(36).substring(2, 3 + Math.random()*8), {
referrerPolicy: "no-referrer",
mode: "no-cors"
});
}, 300);
Translation for non-coders: the page sends about three automated requests per second to the same site while the CAPTCHA is open.
Practical impact
- ~3 requests/sec per open CAPTCHA page → thousands of requests/hour if many visitors have the page open.
- Small/personal blogs with limited CPU or bandwidth can slow, experience timeouts, or become unavailable.
- Because the requests are client-driven, blocking a single IP is ineffective; the traffic originates from many different visitor IPs.
Immediate mitigation steps (for site owners)
- Rate-limit search and heavy endpoints (return HTTP 429 when thresholds are exceeded).
- Deploy CDN/WAF rules to detect and block high-frequency request patterns.
- Ignore or short-circuit obviously random short queries server-side (cheap cached response or 204).
- Collect and retain request logs (timestamps, user agent, referrer) to support abuse reports.
- Consider adding lightweight CAPTCHA or throttling at the endpoint rather than site-wide blocking.
Comments
Post a Comment