DEV Community: Vladislav Rajtmajer

reCAPTCHA-Alternative: DSGVO-konform und EU-gehostet

Vladislav Rajtmajer — Wed, 17 Jun 2026 06:31:00 +0000

Dieser Beitrag erschien zuerst auf captchaapi.eu.

reCAPTCHA ist das CAPTCHA, das die meisten Entwickler zuerst einbauen. Es ist kostenlos, in fünf Minuten integriert und fängt Bots zuverlässig ab. Der Haken zeigt sich erst, wenn jemand aus der Rechtsabteilung oder ein Datenschutzbeauftragter auf die Seite schaut: reCAPTCHA ist ein US-Dienst, und damit hängt an jedem geschützten Formular eine Kette von Pflichten, die seit 2026 vollständig bei Ihnen liegt.

Dieser Beitrag erklärt, was reCAPTCHA datenschutzrechtlich auslöst, warum ein Bußgeldbescheid das nicht nur theoretisch macht, und wie eine EU-gehostete Alternative dieselbe Aufgabe ohne Cookies und ohne Banner löst.

Die kurze Antwort

reCAPTCHA lässt sich DSGVO-konform betreiben, aber die Konformität entsteht nicht durch einen Schalter beim Anbieter, sondern durch das, was Sie drumherum aufsetzen: eine Einwilligung samt Cookie-Banner, eine Risikoabschätzung der Übermittlung in die USA und seit April 2026 die volle Verantwortlichkeit für die Verarbeitung. Wer diese Aufgaben nicht tragen will, ist mit einem CAPTCHA besser bedient, das von vornherein in der EU bleibt und keine Cookies setzt.

Im direkten Vergleich: die vollständige Gegenüberstellung mit reCAPTCHA, hCaptcha, Turnstile und Friendly Captcha zeigt jede Zeile mit den Quellen.

	reCAPTCHA	captchaapi.eu
Betreiber	Google LLC (USA)	Einzelunternehmer (Tschechien, EU)
Hosting	global, US-verankert	nur EU (Hetzner, Nürnberg)
Cookies	ja (`_GRECAPTCHA`)	keine
Cookie-Banner nötig	ja	nein
Übermittlung in die USA	ja (Standarddatenschutzklauseln / DPF)	keine
Abwehr	ML-Risk-Scoring	deterministischer Proof of Work
Kostenlos	10.000/Monat pro Organisation	5.000/Monat, kommerziell erlaubt
Einstiegstarif	ab 8 $ (10.001-100.000)	9 €/Monat (20.000 Anfragen)

Was reCAPTCHA datenschutzrechtlich auslöst

Drei Dinge passieren, sobald ein Besucher auf eine Seite mit reCAPTCHA trifft, und alle drei sind aus DSGVO-Sicht relevant.

Erstens: Daten verlassen die EU. Googles Infrastruktur ist global und in den USA verankert. Seit der EuGH im Verfahren Schrems II (C-311/18) das Privacy Shield gekippt hat, stützt sich jede Übermittlung in die USA auf Standarddatenschutzklauseln plus eine Transferprüfung, die das vom Gericht benannte Überwachungsrisiko berücksichtigen muss. Das EU-US Data Privacy Framework von 2023 hat zwar wieder einen Angemessenheitsweg für zertifizierte Importeure geschaffen, steht aber bereits unter rechtlicher Anfechtung. So oder so verlassen Sie sich auf einen US-Transfermechanismus, statt die Daten gar nicht erst aus der EU zu lassen.

Zweitens: reCAPTCHA setzt Cookies und analysiert seitenübergreifend. Das Widget setzt ein _GRECAPTCHA-Cookie und berechnet einen Risikowert aus dem Verhalten des Besuchers über alle reCAPTCHA-geschützten Seiten hinweg - und, falls er angemeldet ist, zusätzlich aus seinem Google-Kontostatus. Google nennt das "advanced risk analysis"; aus DSGVO-Sicht ist eine solche seitenübergreifende Analyse meines Erachtens als Profiling nach Art. 4 Nr. 4 einzuordnen. (Google gibt an, diese Daten nicht für personalisierte Werbung zu nutzen.) Weil hier nicht nur unbedingt erforderliche Informationen im Spiel sind, brauchen Sie nach § 25 TDDDG und Art. 6 Abs. 1 DSGVO eine Einwilligung, und damit ein Cookie-Banner vor dem Formular.

Drittens: Sie sind seit April 2026 allein verantwortlich. Zum 2. April 2026 tritt Google für reCAPTCHA nur noch als Auftragsverarbeiter auf. Sie waren immer Verantwortlicher, weil Sie entscheiden, warum und wie das CAPTCHA läuft, aber Google hat die Daten zuvor auch für eigene Zwecke verarbeitet. Jetzt liegt die Verantwortung vollständig bei Ihnen, und Googles eigener Migrationshinweis fordert Sie auf, Verweise auf Googles Datenschutzerklärung und Nutzungsbedingungen von Ihrer Seite zu entfernen. Das heißt konkret: AVV prüfen, Transferprüfung dokumentieren, Einwilligung sauber einholen, Informationspflichten nach Art. 13 erfüllen. Alles bei Ihnen.

Der Fall Cityscoot: kein theoretisches Risiko

Dass das kein Papiertiger ist, zeigt ein konkreter Bescheid. Die französische Aufsichtsbehörde CNIL verhängte im März 2023 ein Bußgeld von 125.000 € gegen den Anbieter Cityscoot. Einer der Gründe war der Einsatz von reCAPTCHA ohne vorherige Einwilligung, geahndet nach Art. 82 des französischen Datenschutzgesetzes (Entscheidung SAN-2023-003). Der Punkt ist nicht "reCAPTCHA ist verboten", sondern: ein CAPTCHA, das Cookies setzt und ohne Einwilligung läuft, ist ein bekanntes und bereits geahndetes Risiko.

Wo reCAPTCHA trotzdem gewinnt

Damit das fair bleibt: reCAPTCHA ist technisch stark und bei bestimmtem Traffic schwer zu schlagen. Das ML-Scoring läuft unsichtbar im Hintergrund, und wer normal wirkt, kommt ganz ohne sichtbare Aufgabe durch. Bei sehr hohem Consumer-Traffic, bei dem jede zusätzliche Sekunde Conversion kostet, ist dieser reibungslose Durchlauf ein echter Vorteil. Wenn Sie auf möglichst geringe Reibung optimieren und mit einer Verarbeitung außerhalb der EU einverstanden sind, kann reCAPTCHA die richtige Wahl bleiben.

Der Tausch ist nur eben nicht kostenlos: Sie zahlen ihn in Cookie-Banner, Drittlandtransfer und Verantwortlichkeit.

Die Alternative: nur EU, ab der ersten Anfrage

captchaapi.eu setzt an genau diesem Tausch an. Der Schutz ist deterministischer Proof of Work: Der Browser des Besuchers löst ein kleines Rechenrätsel, bevor das Formular abgeschickt wird. Kein Scoring, das Verhalten über Seiten hinweg auswertet, kein Profil.

Daraus folgt der datenschutzrechtliche Unterschied:

Hosting nur in der EU. Verarbeitung ausschließlich bei Hetzner in Nürnberg. Keine Übermittlung in ein Drittland, also auch keine Transferprüfung und keine Standarddatenschutzklauseln nötig.
Keine Cookies, kein Banner. Das Widget setzt keine Cookies und macht kein Fingerprinting. Die einzige betroffene Information ist die IP-Adresse des Besuchers, und die wird nur als Einweg-Hash (SHA-256 mit serverseitigem Salt) im flüchtigen Cache gehalten, nie in einer Datenbank gespeichert. Damit besteht für die CAPTCHA-Ebene kein Einwilligungserfordernis nach § 25 TDDDG.
AVV liegt vor. Einen vorab unterzeichneten AVV nach Art. 28 gibt es als öffentliche Seite zum Herunterladen, ohne Beschaffungsschleife. Federführende Aufsichtsbehörde ist die tschechische ÚOOÚ.

Der Abwehrmechanismus ist bewusst anders gelagert: Proof of Work hält seine Kosten unter koordinierten Angriffen vorhersehbar, weil sie nicht davon abhängen, dass die Erkennungsgenauigkeit eines Modells stabil bleibt. Und die Entscheidungslogik ist nachvollziehbar statt undurchsichtig.

Tarife

Tarif	reCAPTCHA	captchaapi.eu
Kostenlos	10.000/Monat pro Organisation	5.000/Monat, kommerziell erlaubt
Einstieg	ab 8 $ (10.001-100.000)	9 €/Monat - 20.000 Anfragen
Wachstum	1 $/1.000 darüber	29 €/Monat - 100.000 Anfragen

Der kostenlose Tarif bei captchaapi.eu erlaubt ausdrücklich die kommerzielle Nutzung, und über das Kontingent hinaus werden zahlende Tarife nicht hart blockiert, sondern weiter mit derselben Schwierigkeitsstufe bedient. Der Besucher hat den Tarif nicht ausgesucht, also trägt er auch nicht die Folgen, wenn das Kontingent erschöpft ist.

Umstieg in der Praxis

Der Wechsel ist kein Projekt. Sie tauschen das reCAPTCHA-Skript gegen captcha.js, ersetzen die Server-Prüfung durch einen Aufruf gegen den /verify-Endpoint und entfernen anschließend den Cookie-Banner-Eintrag für das CAPTCHA. Letzteres ist oft die sichtbarste Verbesserung für Ihre Besucher.

Auf WordPress? Den Umstieg gibt es als fertiges Plugin aus dem offiziellen Verzeichnis - es schützt Anmeldung, Registrierung, Kommentare und Contact Form 7 ohne eine Zeile Code und ohne Cookie-Banner. Siehe DSGVO-Captcha für WordPress.

Worum es eigentlich geht

reCAPTCHA ist nicht verschwunden und nicht verboten. Es ist nach dem Wechsel zu Google Cloud nur ehrlicher geworden, was die Rollenverteilung angeht: Die Verantwortung sitzt jetzt klar bei Ihnen. Für einen Anbieter mit EU-Nutzern war die datenschutzrechtliche Lage aber schon vorher der unangenehme Teil - Drittlandtransfer, Einwilligung, Cookie-Banner auf jeder geschützten Seite.

Wenn Sie diese Aufgaben übernehmen wollen, ist reCAPTCHA weiterhin ein solides Werkzeug. Wenn Sie sie lieber gar nicht erst entstehen lassen, ist genau das der Grund, warum dieses Produkt existiert. Kostenlos starten, keine Kreditkarte nötig.

reCAPTCHA-Konditionen: Stand Juni 2026, laut Googles eigener Preisübersicht. Preise und Bedingungen ändern sich - prüfen Sie vor einer Entscheidung die aktuellen Angaben auf Googles Seite.

Laravel RateLimiter and a race condition

Vladislav Rajtmajer — Thu, 14 May 2026 11:38:20 +0000

One of the manual rate-limiting patterns shown in the Laravel docs (under Manually Incrementing Attempts) looks like this:

if (RateLimiter::tooManyAttempts('send-message:'.$user->id, $maxAttempts = 5)) {
    return 'Too many attempts!';
}

RateLimiter::increment('send-message:'.$user->id);

// Send message...

It works fine. Right up until someone hits an endpoint capped at 5 requests per minute with 100 concurrent requests. Then all 100 get through.

I ran into this race condition while building rate limiting for captchaapi.eu, a PoW CAPTCHA API. Credit goes to @_newtonjob, who nailed it in 280 characters in a post on X:

Your Ratelimiting logic works until someone fires 100 concurrent requests on an endpoint that should be limited to 5 requests per minute.
The fix: Ensure you/your agents also check the incremented count returned by RateLimiter::hit() and that it doesn't exceed the max attempts.

(Note: hit() and increment() are aliases — hit() is literally a one-line wrapper that calls increment(). The Laravel docs example used hit() in 8.x and 9.x, then switched to increment() from 10.x onward, but both still work and have identical behavior.)

Here's why it's a problem, the one-line fix, and what I took away from it.

Update (June 2026): After digging into this, I sent a warning to the Laravel docs, right next to the example in question. It got merged — the "Manually Incrementing Attempts" section now flags the race and shows the atomic fix. The rest of this post is unchanged.

Why is it a problem?

Walk through what happens on a single request:

tooManyAttempts() reads the current count from cache
Compares it against $maxAttempts
Returns true or false
If false, the code calls increment(), which bumps the count

That's two independent cache calls. Between step 1 and step 4 there's a window, usually a few microseconds, where another request can read the same stale value, pass the check, and increment too.

At 100 concurrent requests it happens at scale:

Request 1 reads count = 0, passes the check (0 < 5), calls increment() → count = 1
Request 2 reads count = 0 (at the same instant), passes the check, calls increment() → count = 2
...and so on for all 100

The counter ends up at 100, but all 100 requests already ran, and your backend just processed 100x the work you wanted. If the endpoint does something expensive (a PoW challenge, AI inference, an external API call), you just paid for 100 operations instead of 5.

Why the increment is atomic but the check isn't

If you crack open Laravel's source (Illuminate\Cache\RateLimiter::increment() in 12.x):

public function increment($key, $decaySeconds = 60, $amount = 1)
{
    $key = $this->cleanRateLimiterKey($key);

    $this->cache->add(
        $key.':timer', $this->availableAt($decaySeconds), $decaySeconds
    );

    $added = $this->withoutSerializationOrCompression(
        fn () => $this->cache->add($key, 0, $decaySeconds)
    );

    $hits = (int) $this->cache->increment($key, $amount);

    // ...

    return $hits;
}

And hit() is just an alias for increment():

public function hit($key, $decaySeconds = 60)
{
    return $this->increment($key, $decaySeconds);
}

The important part is $this->cache->increment($key, $amount). That's an atomic operation in the cache backend.

I use Redis in captchaapi.eu, where it maps to INCR (or INCRBY), one of the oldest, most battle-tested commands in Redis. It's atomic at the single-key write level: no two concurrent requests will read the same value, and each one gets a unique incremented result back. Memcached has an equivalent incr with the same guarantees.

Here's the key thing: increment() returns the count after the increment. The return value is atomic, deterministic, and unique for every concurrent caller.

$hits = RateLimiter::increment($key);
// With 100 concurrent requests you get return values 1, 2, 3, ..., 100
// (in random order, but each value exactly once)

tooManyAttempts(), on the other hand, is a separate read. It can return a stale value, and the gap between that read and the next write is your race window.

The fix: one increment, check the return value

Drop the two-step pattern (tooManyAttempts → increment) and do it in one:

$attempts = RateLimiter::increment('send-message:'.$user->id);

if ($attempts > $maxAttempts) {
    return 'Too many attempts!';
}

// Send message...

Now with 100 concurrent requests:

Each request gets a unique count after the increment
The first 5 get values 1–5 and pass
The remaining 95 get values 6–100 and get rejected

No window, no race. Redis's atomic increment is the single source of truth, and increment() gives you that truth directly.

One subtle thing worth pointing out: in the original pattern, the increment happens after the check, so any overshoot stays in the counter ("the counter shows 6 even though we didn't want to allow request #6"). In the new pattern you increment every time and check the return value, so the counter might show 100. That's fine, because anything over the limit got rejected. The counter readout looks the same, but the security model is stricter.

`hit()` vs. `increment()`: which one?

They do the same thing. hit() is literally function hit($key, $decay) { return $this->increment($key, $decay); }. The current Laravel docs (10.x+) show increment() in the manual-incrementing example; older versions (8.x, 9.x) used hit(). Both work, pick whichever reads better:

hit() for "register one event," the natural fit for rate limiting
increment() when you want to emphasize the atomic-counter aspect, or bump by more than 1 via the amount: parameter

In captchaapi.eu I went with increment() because it matches the current docs and makes it obvious I care about the return value, not the side effect.

Where this doesn't help

One honest limitation: this protects against the race within a single Redis instance (or a Redis cluster, where each key lives on one shard). If you had Redis split across regions without coordination and an attacker fired requests at every region, INCR's atomicity wouldn't save you. You'd get 100 requests per region, times N regions.

For captchaapi.eu this is plenty, because the whole app runs against a single Redis (Hetzner Nuremberg). For multi-region distributed rate limiting you'd need something like a sliding window log or a token bucket with a centralized source of truth. Different topic.

The other limit: this is a fix for counter-level races. If an attacker rotates IPs (botnet, residential proxy), no per-IP rate limit will stop them. That's a fundamentally different problem, and in captchaapi.eu I handle it with the PoW challenge itself.

One more thing worth being explicit about: for HTTP routes the recommended path in Laravel is the throttle middleware, not manual rate-limiting code. This post is specifically about the manual pattern, which is what you reach for when rate-limiting non-HTTP operations, custom logic inside a controller, or anything where the throttle middleware isn't a fit.

What I took away

A small fix, but a few things clicked for me that hadn't before.

1. "It works" is not the same as "it's secure." I had the documented manual pattern running in production for a while and never saw a bug, because no attacker had shown up at captchaapi.eu yet. These races are quiet. Application logs say nothing, monitoring shows green, and you only find out the limit never actually held when someone with wrk -c 100 decides to take a look. Now any time I review code that rate-limits an expensive operation, I start with: "What happens if 100 requests arrive in the same microsecond?"

2. Return values from atomic operations are code you don't have to write. Redis hands you a unique sequence number for free with every atomic increment. You can use it for rejection, sure, but also for other business logic you'd otherwise solve with more code and more locks. Calling tooManyAttempts() and ignoring increment()'s return value means throwing away information Redis already gave you.

3. The documented manual pattern isn't always the safest one. The Laravel docs showed tooManyAttempts() + increment() (or hit() in older versions) under "Manually Incrementing Attempts" for years, from 8.x onward, with no caveat. It isn't wrong. For most use cases (per-user limits, where users don't realistically make 100 concurrent requests) it's fine. But if you're building something where parallel abuse is the threat model, the docs weren't showing you the safest option. When I ran into it I sent a warning to the docs along with the atomic fix, so it's been on the page since 13.x. Either way, I read documentation a bit differently now: "Who's the assumed user here, and does their threat model match mine?"

4. X is where I pick up security gotchas. This particular fix reached me through a 280-character post from @_newtonjob, not through the docs or a security audit. Following Laravel folks who share concrete pattern-level bugs from real apps has done more for me than most security blog posts. Keep people in your feed who write "I hit X, fixed it like this." That's exactly the kind of pattern matching you need for your own code. Thanks, @_newtonjob.

TL;DR

// ❌ Race-prone — 100 concurrent requests will all get through
if (RateLimiter::tooManyAttempts($key, 5)) {
    return 'Too many!';
}
RateLimiter::increment($key);

// ✅ Race-safe — atomic increment + check the return value
if (RateLimiter::increment($key) > 5) {
    return 'Too many!';
}

One line shorter, one problem gone. If you've got Laravel rate-limiting code using the tooManyAttempts() + increment() (or hit()) two-step pattern, go through it and rewrite to the single-call variant. Especially if you're protecting an operation where every call costs you something.

CAPTCHA without cookies: a proof-of-work approach

Vladislav Rajtmajer — Mon, 11 May 2026 05:39:55 +0000

This post first appeared on captchaapi.eu.

We've all been there. You're trying to sign in, you click "I'm not a robot", and instead of a simple checkbox you get a 3×3 grid of blurry photos. Click all squares with traffic lights. You miss one — was that a real traffic light, or just a pole with a light on top of it? Wrong. New grid. Crosswalks this time. By the third round you've forgotten what you were trying to do in the first place.

That's the visible part. Behind it, there's something less visible: a small army of cookies and trackers that decide whether you "look human" enough to be let through. The cookies do more than rate-limit your CAPTCHA — they feed a cross-site risk model that recognizes a visitor across the sites they touch that use the same provider.

This post is the engineering write-up of how I built a CAPTCHA that doesn't do any of that, and the trade-offs that came with it. It's not a privacy rant; it's an honest engineering question: do CAPTCHAs actually need cookies? Or did we end up with cookies because they were the easiest tool when the problem was first solved, and nobody went back to challenge that assumption after GDPR shifted the cost equation underneath?

Cookies turn out not to be necessary. I built captchaapi.eu without them. Here's how.

What's actually inside reCAPTCHA's data flow

I'll use reCAPTCHA as the canonical example because it's what most EU developers default to. When a visitor hits a page with reCAPTCHA enabled, the following happens in the background:

A _GRECAPTCHA cookie is set on google.com (cross-site cookie via iframe).
If the visitor is logged into a Google account, additional SID, HSID, SSID, APISID, SAPISID cookies are read from the Google account session.
Browser metadata is harvested: user agent, screen resolution, plugins, font list, time zone, language settings.
A risk score is computed from the visitor's activity across the reCAPTCHA-protected sites they've touched, combined with their Google account state when they're signed in.

That last point is what matters for GDPR. The risk model isn't local to your site — it spans the reCAPTCHA-protected sites a visitor touches, plus their Google account state when they're signed in. Google calls it "advanced risk analysis"; from a GDPR perspective it's classic profiling under Article 4(4). (Google states this data is not used for personalised advertising.)

Plus: data leaves the EU. Google's processors are global, anchored in the US. After the Schrems II ruling invalidated Privacy Shield in 2020, EU data transfers to Google require Standard Contractual Clauses or DPF certification, and the transfer impact assessment has to acknowledge the surveillance risk that the CJEU explicitly flagged.

For an EU SaaS asking visitors to "click all squares with traffic lights", that's compliance overhead. It's not technically impossible — Google publishes their DPF certification, you sign their DPA, you tick the boxes. But it's the kind of overhead that creates downstream friction: cookie banners, CMP integrations, DPO sign-offs, and the worry about what happens when the next Schrems judgment lands. I covered the 2026 reCAPTCHA changes and that compliance overhead in more depth in a GDPR-compliant reCAPTCHA alternative.

Why traditional CAPTCHAs need cookies

Cookies aren't in CAPTCHAs because someone decided to be evil. They were there because they solved real engineering problems when the category was first built:

Session continuity. A CAPTCHA challenge has two phases: issue and verify. The server needs to know "this verification request is for that specific challenge". Without state, you have to put the challenge into the cookie itself, signed and timestamped.
Rate limiting per visitor. A bot can fake a User-Agent, but a freshly-minted cookie identifier is a useful (if weak) signal that this is a new session. Cookies give you a stable handle to throttle.
Risk scoring across visits. "This visitor has solved 17 CAPTCHAs in the last 60 seconds" is a useful signal. Without per-visitor identity, you can't accumulate it.
Cross-property correlation. "This visitor is Trusted User™ on 4,000 reCAPTCHA-protected sites" is what makes invisible CAPTCHA possible. Without it, every site evaluates strangers.

Each of these has an alternative when you're willing to redesign the protocol.

The proof-of-work alternative

The shape of a proof-of-work CAPTCHA is very simple:

Server issues a challenge: a random seed plus a difficulty target (a 32-bit integer).
Client iterates a counter, computing SHA-256(seed || counter) until the result is numerically below the target.
Client submits the winning counter (the "nonce") to the server.
Server re-hashes once to verify, accepts if valid.

There's no cookie. The challenge state lives in server-side cache (Redis, 2-minute TTL) keyed by the challenge ID. The client only needs the seed and target, both of which arrive in the issue response. When the client submits the nonce, it submits the challenge ID alongside; the server looks it up, re-hashes, and accepts.

What about rate limiting without cookies? Hash the IP. Specifically: SHA-256(IP || server-secret-salt), held in cache only — up to 2 minutes for the 60-second per-IP rate limiter and up to 24 hours for a cross-sitekey abuse-reputation counter that detects distributed attacks. Never written to disk. This is what GDPR Article 4(5) calls pseudonymisation — the original data can't be recovered without the salt, and the salt never leaves my server. The visitor's actual IP is never persisted.

What about risk scoring without a cross-site profile? Adaptive difficulty per IP rate. If a single hashed IP issues 1,000 challenges in 60 seconds, the difficulty for the next challenge from that IP scales up proportionally. This isn't ML-grade scoring — but it's enough to cost a botnet meaningful CPU time without correlating users across sites.

The trade-off: I'm shifting the cost from "data on the visitor's device" to "CPU on the visitor's device". For tens of milliseconds of SHA-256 work — measured below — no cookie is set, no fingerprint is taken, no cross-site graph is built. For most EU SaaS forms — login, signup, contact, password reset, newsletter — that trade is straightforwardly favourable.

Implementation insights

A few things turned out more interesting than I expected.

The IP hash needs a server-side secret. A naïve SHA-256(IP) is reversible — there are only ~4 billion IPv4 addresses, and a precomputed rainbow table fits on a USB stick. Adding a server-side secret salt makes the hash non-reversible to anyone without server access. In practice this means hashing happens server-side; the client never sees the salt.

Redis matters more than I thought. PostgreSQL would work, but a 2-minute TTL on millions of ephemeral keys is a workload Redis is built for and Postgres isn't. The DB stays out of the hot path entirely; it only sees account data, project keys, and billing records.

Web Workers are non-negotiable. PoW computation on the main thread freezes the UI for visible milliseconds, especially on lower-end devices. Pushing the work into a Worker keeps the page responsive while the math happens in the background. The widget itself is ~19 KB minified, ~7 KB gzipped — small enough that the bundle-size argument against PoW just doesn't apply.

Adaptive difficulty needs to feel invisible to humans. Baseline target is set so a single "fresh" request from any IP completes well under 100 ms on average hardware. Difficulty escalates only when the same hashed IP issues many requests in quick succession. A normal human visitor hitting one form per minute will never see anything but baseline. A botnet trying to brute-force a login page will hit a difficulty wall within seconds.

Server-side is unglamorous. PHP/Laravel + Redis + PostgreSQL on a single Hetzner Cloud server in Nuremberg. No Kubernetes, no microservices. The whole thing runs on hardware that costs less per month than a London lunch.

Real measurements

Numbers are easy to claim and hard to verify, so the widget includes a data-captcha-debug flag that logs the timing breakdown to the browser console. Here's what came back from production captchaapi.eu (the base PoW curve is the same on every plan — these numbers apply uniformly to Free and Business visitors):

Device	PoW solve (median)	Network RTT	Total end-to-end
Mac mini M4 (desktop)	~20 ms	~210 ms	~234 ms
iPhone (Apple Silicon)	~63 ms	~190 ms	~234 ms

Median of 5 runs per device, lucky stochastic outliers (sub-1000 PoW iterations) excluded.

Two things stand out. First, mobile and desktop produce statistically identical total times — not because the iPhone is as fast as an M4 Mac at SHA-256 (it isn't, it's about 3× slower per iteration), but because the PoW work is dwarfed by the HTTPS round-trip to a Nuremberg-anchored EU API. The math is invisible relative to the network.

Second, PoW solve under 100 ms even on a flagship phone — and the curve is tier-agnostic, so this number applies uniformly to every plan from Free to Business. The "PoW captchas are slow on mobile" assumption — which I held myself before measuring — turns out not to survive contact with current Apple Silicon. JavaScriptCore's JIT compiles the SHA-256 loop into something close to native ARM speed. The iPhone runs essentially the same engine architecture as the Mac.

Anyone reading this can verify on their own hardware:

<form data-captcha data-captcha-debug action="/login" method="POST">
    <!-- your fields -->
</form>

Open DevTools console, reload, see four timing lines per challenge. No DevTools Performance traces required.

Honest trade-offs

PoW isn't strictly superior. Here's where it loses:

Sophisticated, well-funded bots. A botnet with cheap CPU can burn through difficulty escalation. ML-based scoring (which is what reCAPTCHA invests in heavily) catches behavioural signals that PoW alone won't.
Mobile battery cost. Tens of milliseconds of SHA-256 work on a phone is a measurable battery hit, even if it's tiny per request — in aggregate, an Apple Silicon phone solving PoW for every form on the web would notice.
Threat-model coverage. PoW protects against "automation by default" — typical scraping bots, opportunistic credential stuffing, low-effort spam. It doesn't protect against ad fraud, account farming for high-value targets, or sophisticated targeted attacks. For those you need behavioural ML, device fingerprinting, or human review.
CAPTCHA-solver services. Networks paying humans 50¢ per 1,000 solved CAPTCHAs work just as well against PoW (the human clicks "Verify" and waits 100 ms — the underlying mechanism doesn't matter to them).

For most EU SaaS use cases — login forms, signup forms, contact forms, comments, newsletter signups, simple bot deterrence — these limitations don't matter. For exchanges, betting platforms, gaming auth, and other high-value targets, layer PoW with additional defences — or use a different category of tool entirely. Honest answer: if you're at that scale, you probably already know.

Why I open-source the widget

The widget code that runs on every visitor's device is published at /captcha.js — minified for size, but not obfuscated. The Proof-of-Work worker code is preserved verbatim with comments inside the bundle. Beautify the file and you can audit byte-for-byte what runs on visitors' devices.

I do this because if I'm running code on someone else's device, they should be able to audit it. The customer who integrates my widget can verify what I'm doing on their visitors' machines. The visitor can verify what I'm doing on their machine. The whole model rests on "I'm not collecting data" — the easiest way to validate that claim is to make the code readable.

It also keeps me honest. Five years from now, when I've forgotten what was important about the design, I'll be able to read my own code and remember. Future-me is one of the people the open bundle is for.

I'd rather be reverse-engineered than trusted blindly. Both are fine. Trusted-after-audit is even better.

A note on what this is and isn't

I should be straight about what I'm shipping, because the legal docs and the trust page already are.

captchaapi.eu is a one-person project. There's no enterprise SLA, no 24/7 on-call rotation, no operator-level ISO 27001 certificate (the underlying Hetzner infrastructure has those; my application layer doesn't, and I refuse to claim certifications I haven't earned). If your procurement team needs those things, this isn't the tool for you yet — and I'd rather tell you upfront than at contract-renewal time.

I'm also not trying to disrupt the CAPTCHA market. I'm not optimising for a revenue curve. I built this because a German customer of mine needed a CAPTCHA on their forms but couldn't reasonably justify reCAPTCHA or Cloudflare Turnstile under their compliance posture, and I went looking for a low-cost EU-only alternative aimed at small developers and small businesses — and the gap was wider than I'd expected. FriendlyCaptcha and a few others exist, but their pricing optimises for enterprise tiers, not for a freelancer or a 5-person startup running a side project at €9 a month. The lower price tiers were missing — and the engineering wasn't actually that hard.

I know that "honesty as a business strategy" is usually a polite way to say "won't scale". Maybe. I care more about shipping a thing I can be proud of than about the curve. If it works out, great; if it doesn't, the code is published, the design write-up is here, and someone else can build the next iteration without re-deriving the protocol.

Closing

GDPR made tracking expensive. Schrems II made US-anchored providers risky. PoW computation on modern devices is cheap enough that the alternative is now just a different kind of "fast enough". If you've been keeping reCAPTCHA on a form because switching seemed complicated — the technical objection has mostly evaporated. PoW CAPTCHAs work, they don't need cookie banners, the widget bundle ships in ~7 KB gzipped.

If captchaapi.eu fits your shape, the Free tier covers 5,000 challenges a month. If you'd rather build your own, the engineering recipe is in this post — go for it. Both are reasonable choices in 2026.

Corrections, technical objections, and missed considerations are welcome at security@captchaapi.eu — I read every email myself.