Wenn der eigene Bot-Schutz Sie aussperrt

Es ist eine eigentümliche Form von Validierung, wenn der eigene Bot-Schutz einem den Zutritt verweigert. Heute Nachmittag haben wir Vercel BotID nicht nur eingeführt, sondern in einem ungeplanten Live-Drill auch gleich getestet — gegen uns selbst.

Was wir geshipt haben

Drei Routen sind ab sofort BotID-gated:

• POST /api/contact — Kontaktformular
• POST /api/newsletter — Newsletter-Signup
• POST /api/chat — der AI-Chat-Endpoint, jeder Call ist ein billable Gateway-Aufruf

Plus <BotIdClient protect={...}> im Root-Layout, damit der Client tatsächlich Interaktions-Signale (Maus, Tastatur, Scroll) auf Outbound-Requests anhängt. Ohne diese Komponente fällt das System auf reine Server-Detection zurück (UA + Header) — gut gegen primitives, leicht zu umgehen von headless Chrome.

Der Plot-Twist

Nach dem Deploy wollten wir verifizieren, dass die neuen Changelog-Einträge live sind. Klassisches Smoke-Test-Skript:

node -e "fetch('https://nex-soft.com/changelog').then(r => r.text()).then(html => console.log(html.includes('8. Snapshot')))"

Antwort:

403 — x-vercel-mitigated: challenge

Unser eigenes Verifikations-Script wurde von unserem eigenen Bot-Schutz blockiert. Sekundenlanges Stutzen. Dann: laute Freude. Das ist genau das, was wir gebaut haben.

Warum das die richtige Reaktion ist

Vercel Firewall + BotID unterscheidet nicht zwischen „böser Bot" und „mein eigenes Smoke-Test-Skript". Aus Sicht der Detection-Engine sehen beide gleich aus: kein Browser, keine Maus-Bewegung, keine BotIdClient-Signale, hohe Request-Frequenz von derselben IP über kurze Zeit. Genau dieses Signal-Set wollen wir blockieren.

Die Alternative wäre, eine Whitelist-Mechanik einzuziehen („dieser Token gehört zum Owner-Team, lass durch"). Die hat aber denselben Schwachpunkt wie jedes Whitelist-System: jemand klaut den Token, schon ist die Whitelist ein Backdoor.

Die echte Lektion: Verifikations-Layer trennen

Wenn Production-Traffic strikt geschützt ist, brauchen Sie einen separaten Verifikations-Pfad. Drei Optionen:

1. Per Vercel CLI inspizieren: npx vercel inspect https://nex-soft.com zeigt direkt welcher Deployment hinter dem Alias hängt, ohne den Edge-Layer zu hitten. Das nutzen wir jetzt für Deploy-Verifikation.
2. Lighthouse via echtem Chrome: Headless Chrome lädt das ganze Page incl. BotIdClient-Script und sieht aus wie ein echter Browser. Unsere npm run audit:lighthouse Pipeline funktioniert deshalb völlig normal weiter — die Audits passieren.
3. Bypass-Token für CI: BotID kennt das Konzept eines „bypass token", den Sie in Server-zu-Server-Aufrufen mitschicken können. Für interne Cron-Jobs oder CI-Smoke-Tests die saubere Lösung.

Wir machen aktuell Variante (1) + (2). Variante (3) kommt sobald wir CI haben.

Was wir nicht erwartet hätten

Die Firewall lernt offenbar dazu. Frühere Smoke-Tests im selben Session-Verlauf gingen durch. Erst nach ~20 Requests in 30 Minuten begann die Mitigation zu greifen. Das ist ein Feature, kein Bug — Rate-basierte Detection braucht ein bisschen Signal-Sammeln, bevor sie konfident genug ist zu blockieren.

Für eine Marketing-Site mit drei POST-Endpoints ist das Verhalten gold wert: kein menschlicher User wird je in diese Schwelle reinlaufen, aber jeder Scraper schon nach wenigen Versuchen.

Was es kostet

Praktisch nichts. <BotIdClient> ist ein ~10kb Script, lazy-loaded, das auf protected paths Signale anhängt. Server-side ist checkBotId() ein millisecond-call. Vercel-Pricing: free tier reicht für die meisten kleinen Sites; das billable cap kicked erst bei wirklich hohem Volume.

Verglichen mit der Alternative — ein Bot drained Ihr AI-Gateway-Budget über Nacht um €200 — ist das ein No-Brainer.

TL;DR

• BotID + Firewall auf teuren POST-Endpoints (besonders AI) ist Pflicht-Hygiene 2026.
• Wenn das eigene Test-Skript geblockt wird: Glückwunsch, es funktioniert.
• Planen Sie einen separaten Verifikations-Pfad (CLI / Lighthouse / Bypass-Token), bevor Sie ihn brauchen.
• Production Defense ist nicht: „lass alles durch was nicht eindeutig böse aussieht". Production Defense ist: „lass nur durch was eindeutig menschlich aussieht."

Wenn Sie gerade Ihr erstes AI-Feature in Production bringen und überlegen „brauchen wir BotID?": Ja. Bevor Sie es brauchen, nicht danach.