How Kasada Bot Detection Works

Where Kasada sits and how to spot it

Kasada sells bot defense for websites, mobile apps and APIs. Its own data sheet describes the service as "architected as an alternate origin for sensitive application components": protected routes such as login, search, checkout or a product API are served through Kasada's layer, while the rest of the site may not be. That is why a crawler can read a public category page and then fail on the same site's search endpoint a minute later.

The same document lists the design choices that shape everything below: no CAPTCHA, invisibility to normal users, heavy obfuscation of its client code and independence from any particular CDN. Kasada's homepage still leads with stopping attacks "without CAPTCHAs" and now adds control over which AI agents can reach which endpoints.

You usually notice Kasada indirectly. A request that worked in a desktop browser fails from a script, often with HTTP 429 and a short HTML body that loads a script instead of the content you expected. Developers who inspect those exchanges commonly report response and request headers whose names begin with x-kpsdk. Treat those markers as a hint, not proof: the dependable sources are the site's own cookie or privacy disclosure and, when you have a business relationship, the site owner.

Before you go further, decide what you are trying to do. If you are a customer whose normal browser is challenged, the fix is usually local (extensions, an outdated browser, a shared network). If you run an automated collector, the real question is whether the site permits it, which the last section covers.

Client interrogation and proof-of-work

Kasada describes two client-side mechanisms, and they do different jobs.

Interrogating the client

The data sheet says Kasada's "sensor detection technology with advanced Javascript inspection processes" classifies bots as benign or malicious, and that the platform produces "immutable evidence of automated attacks". In an earlier engineering post, Mastery of the puppets, the company says the same inspection lets it tell "a common browser versus an attack tool such as Puppeteer".

In practice, client interrogation means the script asks the runtime questions that a real browser answers in a consistent way and an automation stack often does not. Examples of the categories involved, from public browser standards rather than Kasada's private code:

• Automation flags. The W3C WebDriver specification defines navigator.webdriver, which returns true when the browser is under remote control. Stock Selenium and Playwright sessions expose it.
• Engine behavior. Rendering, timing and API side effects are produced by the real engine. A script that patches one property rarely patches the dozens of related answers that should change with it.
• Coherence. The user agent string, client hints, screen and window sizes, fonts, language and time zone should describe one plausible device. Each value can look normal while the combination does not.

The code that asks these questions is obfuscated and changes over time. Kasada lists obfuscation among its core features, so any write-up that claims to describe the current script field by field is describing a snapshot.

Making each request cost something

The second mechanism is economic. According to the data sheet, "a cryptographic browser-based challenge is used as a proof of work that exponentially increases the difficulty level with the number of abusive requests over time". An AWS Startups profile of the company from January 2019 describes the same idea: suspected bots receive a challenge that grows harder, so the attack burns its own computing budget.

For a person loading a page, the work is small and invisible. For a script making thousands of requests, it becomes the dominant cost. That design explains a common pattern: a collector that solves the first challenge still slows down and then fails as its volume rises, because the price of each request keeps climbing.

Network signals

Kasada's public material says little about IP reputation, and it would be a mistake to treat its product as an IP blocklist. Still, every bot-defense system sees the connection, and three network facts are worth getting right because they are easy to get wrong.

First, the address type. Requests from cloud hosting ranges look like servers, because they are. Commercial databases label them: MaxMind's Anonymous IP database, for instance, flags hosting providers and public proxies as separate categories. A line on a mobile carrier is classified as that carrier's network, which is what a phone on the same network would show.

Second, the transport fingerprint. The TLS Client Hello and the HTTP/2 settings a client sends identify the software that built the connection. A Python HTTP library and Chrome produce different fingerprints even when they send the same headers. Our guide to JA3 and JA4 explains how those fingerprints are computed, and the JA4 checker shows what your own client sends.

Third, the operating system signals in TCP/IP headers. A browser that says it runs on Windows while its packets carry Linux defaults is a mismatch some systems record. TCP/IP fingerprinting and p0f covers that layer in detail.

The network layer can make an honest client look out of place. It cannot make a dishonest client look honest. If the browser fails interrogation, no address fixes that.

Why headless and HTTP clients fail

Three kinds of client fail in predictable ways, and it helps to know which one you have before changing anything.

Plain HTTP libraries

Requests, HTTPX, Axios and similar libraries do not run JavaScript. They cannot execute the challenge, so they never hold the token that later requests need. Changing headers or the user agent string does not change that, and copying a token from a browser only works until it expires or the difficulty rises.

Default automation browsers

Selenium, Playwright and Puppeteer drive a real engine, so they can run the script. Out of the box they also announce automation through navigator.webdriver, through launch flags and through differences between headless and headed modes. Kasada's 2021 platform update, as reported by Help Net Security, said its interrogation had expanded specifically to identify Puppeteer, Playwright and stealth plugins.

Patched browsers and solver services

Patching every property a detector might read is a moving target, and each patch can create a new inconsistency. Services that hand out solved tokens move the problem rather than solving it, and they put the operator further outside the site's terms. We do not publish evasion code for specific vendors or sites, and this guide stops at explaining why the approaches break.

The shared lesson: Kasada checks whether the client is what it claims to be. The only stable answer is a client that is what it claims to be.

What a consistent setup needs

If you have permission to automate a Kasada-protected flow (your own site, a partner's site, or a QA contract), the goal is a session that a reviewer would recognize as a normal browser on a normal device. Five points cover most failures we see in diagnosis.

1. A real, current browser. Use a maintained build of Chrome, Edge or Firefox in headed mode, with its own profile. Keep it updated; a browser several versions behind is itself unusual.
2. One coherent identity. The user agent, client hints, language, time zone, screen size and fonts should describe the device you are actually using. If you route through another country, set the time zone and language to match, or expect the mismatch to be noticed.
3. A matching network path. The exit IP, its country and its network type should fit the identity. For mobile-app or mobile-web testing, a carrier line makes the session look like the audience it serves. Coronium's mobile proxies are physical devices with their own SIM, one customer per line, reachable over HTTP and SOCKS5.
4. Leak checks. Confirm that WebRTC and DNS do not reveal a different address with the WebRTC leak test and the DNS leak test. A leak tells the site two different stories about where you are.
5. Human pacing. Keep one session on one IP, rotate between sessions rather than during them, and keep request volume close to what one person would generate. Proof-of-work punishes volume, so a slow, permitted job outlasts a fast one.

The broader detection stack, including how these layers combine, is covered in how websites detect proxies. For DataDome and Akamai, which weigh the same layers differently, see the guides to DataDome and Akamai Bot Manager.

Terms and legal notes

Bot defense is a statement of intent by the site owner. Working around it can breach the site's terms even when the data is publicly visible, and in some places it can raise legal questions beyond contract.

In the United States, the Supreme Court's 2021 decision in Van Buren v. United States narrowed the federal computer misuse statute to access beyond the areas a person is entitled to reach. That decision did not make every collection method lawful, and contract, copyright, privacy and state law still apply. Our overview of web scraping law covers the main questions by region.

Practical rules that keep you out of trouble:

• Check whether the site offers an API, a feed, an affiliate program or a data license, and use it.
• Never collect personal data you have no lawful basis to hold, and never collect behind a login you are not authorized to use.
• Respect robots.txt and rate limits, identify your client where the site asks for it, and stop when the site objects.
• Keep records of the permission you rely on.

Kasada now markets controls for declared AI agents as well as for unwanted bots. Its January 2026 AI Agent Trust launch, reported by Security Boulevard, describes verified-agent policies with support for standards such as Web Bot Auth. If you operate an agent, declaring it is the route that improves over time. Our guide on why AI agents get blocked covers that path.

Frequently asked questions