How Kasada Works (2026)

Kasada is a reverse-proxy WAF: it stands between visitors and the real server (the origin), inspecting every request before passing it on. It gives each request a trust score based on the reputation of your IP address, the output of its in-browser VM, the details of your TLS handshake (TLS is the encryption layer behind https), and how you behave on the page.

Requests it does not trust get one of two responses:

• A silent 429 Too Many Requests carrying x-kpsdk-* headers — often on your very first request. That is a giveaway that you are dealing with Kasada, not a sign that you actually sent too many requests.
• A proof-of-work challenge served from /ips.js or /p.js — a puzzle the browser must solve before any further request is accepted.

1. IP address reputation

Where your connection comes from sets a starting trust level:

• Datacenter IPs (AWS, GCP, Azure, DigitalOcean, OVH…) — addresses owned by cloud providers, scored low from the start. Kasada is especially harsh here; most cloud ranges are blocked outright on protected sites.
• Residential IPs — addresses ISPs hand out to home internet connections. Higher baseline trust.
• Mobile IPs — addresses from cell towers and carrier networks (CGNAT). Highest baseline trust.

2. The Kasada VM and proof-of-work

This is what Kasada is unique for. Instead of shipping a readable (if minified) detection script, Kasada sends a VM-bytecode payload (ips.js / p.js): scrambled instructions run by a tiny custom interpreter bundled in the same file. That VM creates two headers that authorise your next requests:

• x-kpsdk-ct — a client token tied to your device fingerprint (the unique profile Kasada builds of your browser).
• x-kpsdk-cd — the proof-of-work result, a calculation that costs a real browser roughly 100ms of CPU time. Headless browsers or attempts to compute it elsewhere get throttled.

The VM also gathers the usual fingerprint surface — canvas/WebGL rendering, audio context, installed fonts, screen size, timezone, the navigator.webdriver flag, the shape of the window.chrome object, the plugin list — and folds it into the bytecode's internal state. Because that bytecode rotates frequently, pre-built solvers stop working within weeks.

3. HTTP and TLS fingerprinting

Before any HTML is exchanged, Kasada fingerprints you from the TLS handshake (summarised as a JA3/JA4 hash) and from how you speak HTTP/2.

• Most scraping libraries still default to the older HTTP/1.1. Real Chrome and Firefox stopped doing that years ago.
• libcurl and Go's net/http produce JA3 signatures that match no real browser.
• HTTP/2 fingerprinting tracks the order of pseudo-headers, SETTINGS frame values, and window-update sizes — low-level details that differ between real browsers and bots.

4. Behavioural and pattern analysis

Kasada also runs continuous machine-learning analysis looking for tell-tale patterns:

• Missing headers that real browsers always send (Sec-Fetch-*, Accept-Language, sec-ch-ua).
• x-kpsdk-* tokens from an earlier response now arriving from a different IP.
• The same proof-of-work result reused across many requests instead of being recomputed for each page load.
• Hits on honeypot links (decoy links invisible to humans but followed by bots).
• Bursty, machine-like timing.

With Kasada, the VM matters more than anything else: without a valid x-kpsdk-cd, no other signal can save your request. There are three broad categories of tooling:

• HTTP clients with browser-impersonating TLS — curl_cffi, curl-impersonate, tls-client. These copy a real browser's handshake, but they cannot run the VM.
• Full-stack real browsers — Camoufox, patchright, Playwright with consistent browser configuration. These run the VM inside a real browser, so the proof-of-work gets computed.
• Managed scraping APIs — services that keep up with the frequent ips.js rotations for you.

Reusing the same session value across requests keeps your x-kpsdk-* tokens and trust score warm. Computing a fresh proof-of-work on every single request is both slow and a strong sign of automation.

Mostly real-estate, retail, hospitality and ticketing sites. Many of these switch between Kasada, Cloudflare, Akamai, DataDome and PerimeterX depending on conditions.

Kasada builds a running trust score from four things: IP reputation, the ips.js VM and its proof-of-work output, TLS/HTTP/2 fingerprints, and behavioural patterns. The VM is the most distinctive piece — trying to crack it by reading the code stops working quickly because the bytecode rotates, which is why running it in a real browser is the dominant approach in production.