--- title: "Kasada 2026 umgehen: Anleitung" slug: how-to-bypass-kasada date: 2026-10-07T06:15:10+00:00 modified: 2026-10-07T06:15:12+00:00 permalink: https://brightdata.de/blog/wie/how-to-bypass-kasada type: blog --- [ Blog ](https://brightdata.de/blog "Blog") / [How Tos](https://brightdata.de/blog/wie) [How Tos](https://brightdata.de/blog/wie) # Kasada 2026 umgehen: Anleitung Warum Kasadas x-kpsdk-ct-Token Scraper blockiert, was die ips.js-VM prüft, und wann du einen Solver baust oder Bright Datas Web Unlocker nutzt. 22 min lesen [ ![Satyam Tripathi](https://media.brightdata.de/2024/09/Satyam-Tripathi-50x50.png) ](https://brightdata.com/blog/authors/satyam-tripathi) [Satyam Tripathi Technical Writer ](https://brightdata.com/blog/authors/satyam-tripathi) ![How to Bypass Kasada](https://media.brightdata.de/2026/10/How-to-Bypass-Kasada-in-2026.png) Wenn dein Scraper einen HTTP 429 oder 403 mit `x-kpsdk-*`-Headern erhält, blockiert Kasada ihn, und die Antwort erklärt nicht warum. Kasada ist eine Anti-Bot-Plattform, die Websites, APIs und mobile Apps vor automatisiertem Traffic schützt. Sie führt eine verschleierte JavaScript-Challenge im Browser aus, bewertet den Client und stellt ein kurzlebiges Token aus, das jede spätere Anfrage enthalten muss. Um Kasada zu umgehen, musst du zuerst wissen, was dieses Challenge-Skript prüft. Ich habe ein echtes analysiert, und das Ergebnis entscheidet, ob du einen Solver baust oder kaufst. ## Kurzfassung - Kasada benötigt ein gültiges Token: `x-kpsdk-ct` kommt nur durch das Abschließen der JavaScript-Challenge zustande, daher reicht TLS-Impersonation allein nicht aus. - Die Challenge ändert sich bei jeder Anfrage: Es ist eine eigene virtuelle Maschine, sodass ein kopierter Solver innerhalb von Stunden nicht mehr funktioniert. - Automatisierte Browser hinterlassen Signale: Ein Standard-Setup zeigt `navigator.webdriver`, einen `HeadlessChrome`-User-Agent und Namen von Automatisierungs-Frameworks, die Kasada erkennen kann. - Du kannst bauen oder kaufen: Einen Solver zu warten ist laufende Arbeit, während Bright Datas Web Unlocker die Challenge für dich löst und pro erfolgreicher Anfrage abrechnet. ## So bestätigst du, dass eine Website Kasada verwendet Ein 403 oder 429 sagt dir, dass etwas die Anfrage blockiert hat. Es sagt dir nicht, welches System es war, und diese Antwort entscheidet alles Weitere. Cloudflare, DataDome, Akamai und Kasada geben alle dieselben Statuscodes zurück, sodass der Code allein das System nicht identifizieren kann. Die Header und Cookies jedes Anbieters identifizieren es, und du kannst sie mit 1 Anfrage auslesen: ```none curl -sI https://target.example/ | grep -i \ -e '^x-kpsdk' -e '^set-cookie: kp_uidz' \ -e '^cf-ray:' -e '^set-cookie: __cf_bm' -e '^server: cloudflare' \ -e '^x-datadome' -e '^set-cookie: datadome' \ -e '^server: akamaighost' -e '^set-cookie: _abck' ``` Suche vom Anfang der Header-Zeile an (das macht das `^`), nicht irgendwo in der Zeile. Ein breites `grep -i akamai` trifft auch auf nicht verwandte Header, die einen CDN-Hostnamen enthalten, etwa die Content-Security-Policy der Seite, und liefert falsch-positive Ergebnisse. Jedes System hat eine andere Signatur. Die Kasada-Zeile stammt aus meiner eigenen Erfassung, und die anderen Zeilen stammen aus der öffentlichen Dokumentation der jeweiligen Anbieter: Was die Antwort enthältDas System ist`x-kpsdk-*`-Header und ein `KP_UIDz`-Cookie, plus ein `ips.js`-Skript, das `window.KPSDK` setztKasada`cf-ray`-Header, `__cf_bm`-Cookie, `server: cloudflare`Cloudflare`x-datadome`-Header und ein `datadome`-CookieDataDome`server: AkamaiGHost` bei einer blockierten Antwort, oder ein `_abck`-Cookie bei einer erlaubten AntwortAkamaiWenn du einen `x-kpsdk-*`-Header siehst, ist das System Kasada. Siehst du einen der anderen, gelten die folgenden Kasada-spezifischen Schritte nicht, und Bright Datas Anleitungen zum [Umgehen von Cloudflare](/blog/web-data/bypass-cloudflare) und zur [Akamai-Bot-Erkennung](/blog/web-data/bypass-akamai-bot-detection) decken diese Systeme ab. ## Was Kasada prüft, bevor es einem Client Zugriff gewährt Kasada verlässt sich nicht auf ein einziges Signal. Es nutzt mehrere Ebenen, und eine Anfrage muss alle bestehen, um ein Token zu erhalten. Das Verständnis der Ebenen erklärt, warum eine Lösung, die gegen ein einfacheres System funktioniert, hier wirkungslos bleibt. Die erste Ebene ist die IP-Reputation. Kasada prüft die Reputation der IP-Adresse und ihrer Autonomous System Number (das Netzwerk, zu dem die Adresse gehört). Ein Datacenter-IP-Bereich, den bereits viele Scraper genutzt haben, hat einen schlechten Ruf, noch bevor du einen einzigen Header sendest. Residential-IP-Adressen von echten Verbraucher-ISPs haben eine bessere Reputation, weil echte Nutzer über dieselben Netzwerke verbunden sind. Die zweite Ebene ist das TLS-Fingerprinting. Kasada liest den TLS-Handshake und die HTTP/2-Einstellungen und vergleicht sie mit dem, was ein echter Browser sendet. Ein Standard-Python-Client bietet Cipher Suites und Erweiterungen in einer Reihenfolge an, die kein Browser verwendet, sodass der Fingerabdruck nicht zum angegebenen User-Agent passt. [Wie TLS-Fingerprinting funktioniert](/blog/web-data/tls-fingerprinting) behandelt das ausführlicher. Die dritte Ebene ist die JavaScript-Challenge. Kasada sendet ein verschleiertes Skript an deinen Client und prüft, was er zurückgibt. Das Skript erstellt einen Fingerabdruck der Laufzeitumgebung, führt eine Proof-of-Work-Berechnung aus (ein Rätsel, das der Client lösen muss) und kombiniert beides zu einem verschlüsselten Paket. Die vierte Ebene ist der Token-Lebenszyklus, den ich aus der Funktionsweise des Protokolls abgeleitet, aber nicht direkt erfasst habe, und die fünfte ist die Verhaltensanalyse, die ich nicht getestet habe. Eine gute IP und ein passender TLS-Handshake erfüllen nur die Ebenen 1 und 2, daher konzentrieren sich die folgenden Abschnitte auf die Ebenen 3 und 4. In der Reihenfolge, in der eine Anfrage sie durchläuft, sehen die Ebenen so aus: ![Diagramm der Kasada-Erkennungsebenen, die eine Anfrage durchlaufen muss, um ein Token zu erhalten, von der IP-Reputation bis zur Verhaltensanalyse.](https://media.brightdata.com/2026/10/Hyceka1sMx.png)## Wie die Kasada-ips.js-Challenge funktioniert Die ips.js-Challenge ist eine eigene virtuelle Maschine, daher zeigt das Lesen des Skripts nicht, was sie prüft. Um es direkt zu sehen, habe ich eine von Kasada geschützte Seite angefragt und die Antwort gelesen. Das Ziel war eine öffentliche Immobilien-Website, und die Antwort war ein 429 statt der Seite. ### Die 429-Antwort und das ips.js-Skript Die Antwort enthielt die Kasada-Header und einen kleinen HTML-Body, der die Challenge startet: ```none HTTP/2 429 x-kpsdk-r: 1-AA x-kpsdk-ct: content-type: text/html; charset=utf-8 access-control-expose-headers: x-kpsdk-ct,x-kpsdk-r,x-kpsdk-c,x-kpsdk-h,x-kpsdk-fc set-cookie: KP_UIDz-ssn= ``` Du kannst dieselben Header selbst in den Chrome DevTools sehen, bei der ersten Anfrage im Network-Tab (der rote Eintrag oben in der Liste): ![DevTools-Headers-Bereich für die 429-Antwort, mit x-kpsdk-ct, x-kpsdk-r und KP_UIDz-Cookies mit verborgenen Werten.](https://media.brightdata.com/2026/10/Hyef1a1jfx.png)Der 429 ist die Challenge selbst, kein Rate-Limit, und er enthält ein initiales Token und ein Script-Tag. Der Body setzt ein `window.KPSDK`-Objekt und lädt das Challenge-Skript von einem Pfad, der für jede geschützte Website eindeutig ist: ```none