Why does Anubis prefer JavaScript instead of a server-side check?

If you’ve ever come across an anti-bot or challenge page on a website, you might wonder why some sites insist on using JavaScript-based checks rather than just server-side verifications. The Anubis bot deterrence system is a great example of a design that leverages client-side Proof-of-Work (PoW) in modern browsers — and it’s chosen that route intentionally to balance security, server load, and user experience.

In this post, I’ll take you through why anti-bot pages exist, offer a plain-English explanation of Proof-of-Work, dig into the history of Hashcash, and discuss why JavaScript is the preferred approach for Anubis instead of server-side PoW checks.

Why anti-bot pages exist: a quick overview

Websites, especially those handling sensitive data or high volumes of traffic, face automated threats every day. Here are some of the common issues that motivate anti-bot challenges:

Scraping and data theft: Automated bots crawl websites to steal content or data, often for commercial use.
Credential stuffing and brute force: Bots try to guess user passwords or perform large-scale login attempts.
Spam and abuse: Bots create fake accounts, spam forms, or try to scam users.
Infrastructure overload: High bot traffic can stress or crash servers, causing outages and delays for real users.

To combat these, websites often insert an "anti-bot page" — a challenge that distinguishes real humans from bots. The key challenge is designing one that deters bad bots without burdening legitimate users or servers.

Common anti-bot methods

Anti-bot checks take many forms. A few are:

CAPTCHAs: Tests like selecting all images with traffic lights (image CAPTCHAs) are well-known but may annoy users, impact accessibility, and sometimes can be bypassed by sophisticated bots.
Hidden form fields or timing checks: Detect non-human interaction patterns but may generate false positives.
IP reputation and rate limiting: Block or throttle suspicious IP addresses but can block legitimate users behind shared IPs.
Proof-of-Work (PoW): Requires clients to perform a computationally expensive task before gaining access, making automated attacks more costly.

Anubis focuses on the last approach, using client-side Proof-of-Work done via JavaScript. Let’s break down what Proof-of-Work means in this context.

Proof-of-Work in plain English

Proof-of-Work (PoW) is a concept where a party must solve a computational puzzle to prove they have spent a certain amount of computing effort before being granted access or rights.

Think of it like a quick but challenging task, such as:

Finding a number (called a nonce) that makes a hash start with a certain number of zeros.
Solving a math puzzle that requires repeated trial and error.

The key things about PoW are:

It costs the challenger time and CPU cycles. Unlike a password check, you need to actually crunch numbers.
It’s easy for the server to verify. Once the client sends their answer, the server can quickly check if it’s valid by running a simple hash one time.
It levels the playing field. For automated bots that make many requests, the total cost adds up, thus making attacks more expensive.
Easier for humans to pass. Humans usually only do the task once or a few times, so the delay is short and bearable.

In Anubis, this PoW task is done on the user’s browser using JavaScript. That way, the user’s device does the hard work, not the server.

The original inspiration: Hashcash

Proof-of-Work isn’t new. The original, well-known scheme called Hashcash was introduced in 1997 by Adam Back as a way to reduce spam emails. In simple terms:

The sender had to compute a hash value with a certain number of leading zeros by trying many possible values.
This slowed down bulk spammers cheaply sending millions of emails.
Recipients could quickly check the solution — making it effective and efficient.

Since then, PoW became famous as the mining mechanism behind Bitcoin and other cryptocurrencies, but its utility goes beyond digital money. Anubis uses this proven PoW idea adapted to HTTP requests and to browsers.

Why JavaScript: client-side PoW for server load reduction

Now, you may wonder — why does Anubis prefer doing Proof-of-Work inside the browser with JavaScript versus performing the check server-side?

Aspect JavaScript Client-Side PoW (Anubis) Server-Side PoW Who does the work? User's device (browser CPU) Server CPU Server resource impact Minimal, because server only verifies result High, server does all computations Scalability High, leverages client computers Limited, server CPU can bottleneck User environment requirement Modern JavaScript-capable browser No client requirements Resistance to bot adaptation Strong, since bot must solve PoW on-client Effective, but server cost grows User experience Fast after initial computation (~seconds), no CAPTCHA puzzles Depends on server delay, no visual challenge

1. Offloading CPU work to clients saves server load

When a server forces PoW on its side, it must compute or at least partially perform resource-heavy calculations for every suspicious request. This quickly adds up with volume and risks server overload.

By contrast, Anubis asks the client (your browser) to do the "hard" part — crunch numbers to find a valid nonce. The server then just verifies one hash quickly. This distributes load across users rather than bottlenecking the website's backend machines.

2. Modern browsers can handle PoW efficiently

Today’s browsers have powerful JavaScript engines optimized over years. They can handle complex math (like SHA-256 hashing used in PoW) efficiently without noticeably bogging down the user’s machine.

Additionally, JavaScript supports:

Typed arrays and bitwise operations for fast hashing at a low level.
Web Workers to run PoW computations in parallel without freezing the page.
Asynchronous processing so PoW runs smoothly in background while UI remains responsive.

3. Bot deterrence by design

Using JavaScript based PoW raises the barrier for bots, because:

They need to execute actual code, which is harder to fake or shortcut without a real browser environment.
Mass distributed bots now pay CPU cost per request, making large attacks costly.
This approach favors real users who usually only solve the challenge once per session.

JavaScript requirements and modern browser features for Anubis

Of course, there are tradeoffs. Anubis requires the user’s browser to:

Support JavaScript and ES6 features: Including Promises, typed arrays (Uint8Array), and bitwise operations.
Allow cryptographic hashing: Either via built-in Web Crypto API or efficient JavaScript implementations.
Not disable JavaScript due to privacy or security settings.

Fortunately, the last decade of browser development means the vast majority of active desktop and mobile browsers meet these criteria.

How Anubis handles less capable browsers

If a browser cannot or does not run the PoW code:

The user may be presented with a fallback CAPTCHA or a different anti-bot mechanism.
In very rare cases, users might be unable to proceed until the challenge is passed (since JavaScript is fundamental here).

This fallback design respects both security needs and user accessibility.

Browser quirks checklist for Anubis users

If you encounter trouble passing an Anubis anti-bot page, here’s a quick checklist to help:

Make sure JavaScript is enabled in your browser settings.
Disable NoScript or similar browser extensions temporarily.
Try clearing only your browser cache and cookies related to the site (not all browsing data).
Ensure your browser version is up to date for proper ES6 support.
Disable any VPN or proxy that might block or alter scripts.

This boerse-social.com list avoids vague "clear everything" steps and focuses on actionable fixes that keep protections working properly.

Summary: why Anubis prefers client-side JavaScript checks

To wrap up, here’s why Anubis uses JavaScript-based client-side Proof-of-Work instead of server-side checks:

Reduces server load: The server avoids heavy CPU use by shifting complex calculations to the client's browser.
Deters bots effectively: The cost of solving puzzles at the client-side makes automated attacks expensive and less feasible.
Leverages modern browser features: Efficient JavaScript engines and Web Crypto APIs make PoW practical in real user environments.
Maintains user experience: Non-intrusive, fast challenges that don’t require tedious CAPTCHAs.
Uses proven cryptographic principles: Drawing from Hashcash ideas optimized for today’s web traffic challenges.

While no method is perfect, Anubis strikes a balanced approach, protecting online resources while keeping access smooth for legitimate users.

Written by a web operations and abuse-prevention specialist. For questions or feedback, feel free to reach out.