Bot management · Kasada

Kasada

Difficulty 5/5

Proof-of-work plus a VM-obfuscated client. Deliberately expensive to automate: it makes bots pay CPU time rather than trying to out-guess them.

How it decides

A client-side proof-of-work the browser must compute before a token is issued — cheap once, ruinous at scale.
A bytecode-VM obfuscated sensor whose logic is regenerated regularly, so any static bypass has a short shelf life.
`x-kpsdk-ct` / `x-kpsdk-cd` request headers carrying the issued token and its timing.
Silent failure: an unsolved request usually gets a 429 with an empty body rather than a readable block page.

HTTP 429 with a zero-length body and no explanation
`x-kpsdk-ct`, `x-kpsdk-cd` or `x-kpsdk-v` headers
A script path shaped like `/149e9513-01fa-4fb0-aad4-566afd725d1b/.../p.js`
A page that loads fine in a browser but returns nothing to every HTTP client you try

Publicly observable artefacts Kasada sends to every visitor. Paste a response into the analyser and these are what it looks for.

Where	Signal	Weight
Header	x-kpsdk-ct token header	80
Header	x-kpsdk-cd header	75
Header	x-kpsdk-v version header	70
Header	x-kpsdk-r header	65
Page markup	Kasada client script path	80
Page markup	KPSDK client reference	60
Status	429 with no body — Kasada’s usual denial	15

A real browser, always. Kasada is the least tractable vendor for request-level automation.
Budget CPU, not just addresses — the proof-of-work is the intended cost, and it is per-session.
Residential exits plus low concurrency. Volume is what makes the proof-of-work hurt.
Expect maintenance. The obfuscated client rotates, so anything brittle breaks on their schedule, not yours.

From the detector's curated database. Observed, not live — stacks change, and large sites often run different protection per market.

Paste the response you actually got. The detector names the vendor from its own headers, cookies and challenge markup — no account, nothing uploaded.