When a reverse proxy spots suspicious traffic from an IP or ASN, it has two broad choices: block it outright, or challenge it. Blocking risks turning away real users caught in the same net; a challenge lets legitimate visitors prove themselves while filtering out automated clients. Two challenge types dominate — JavaScript challenges and CAPTCHAs — and choosing between them is really a choice about how much friction you are willing to impose on real people.
JavaScript Challenges
The proxy returns a page containing a small JavaScript puzzle. A real browser executes it, solves it and sets a verification cookie — all invisibly, usually in under a second. A visitor sees, at most, a brief flash. Most automated attack tools do not run a full JavaScript engine, so they simply fail and receive no content. The great advantage is zero friction: legitimate users are not asked to do anything.
CAPTCHA Challenges
A CAPTCHA asks the user to actively prove they are human — identify images, tick a box, solve audio. This catches more sophisticated bots, including some that can run JavaScript but cannot solve a visual puzzle. The cost is real: CAPTCHAs add friction, measurably reduce conversion, and create accessibility barriers for users with visual or motor disabilities. They belong on high-value actions, not on the front door of every page.
- JS challenge: zero friction, invisible, blocks most simple bots — but a determined headless browser can pass it.
- CAPTCHA: visible friction, stops most bots, poor accessibility, and typically a 5–15% user drop-off at the challenge itself.
- Behavioural / checkbox challenges: lower friction, using signals like mouse movement and timing to judge humanness.
Friction is a cost, not a feature
Every challenge you show a real user is a small tax on conversion and accessibility. The goal is the least friction that stops the attack — which usually means an invisible check by default and a visible one only where the stakes justify it.
How to Choose — and How Akarguard Applies It
The practical rule: use JavaScript challenges as the default for suspicious traffic during an attack, because they cost real users nothing, and reserve CAPTCHA for specific high-value endpoints — login, checkout, signup — that are being actively targeted with credential stuffing or abuse. Never put a CAPTCHA on general page traffic; the conversion loss outweighs the security gain. Akarguard follows exactly this model: per-domain protection modes apply an invisible JavaScript/cookie check by default and escalate to a CAPTCHA mode only where you choose, so protection scales with the threat instead of taxing every visitor.