Kasada Bypass in 2026: We Actually Tested It Against 9 Confirmed-Protected Sites

If you've tried scraping a site protected by Kasada, you've probably seen this: the page loads fine in your browser, and the same request from a scraper comes back empty.

Search "Kasada bypass 2026" and you'll find plenty of guides. Most list the same stealth browsers and the same two header names. Almost none say which sites they tested, and several name sites that, when we checked, turned out to be protected by a completely different vendor.

So we ran our own test. We started from Kasada's published case studies, confirmed nine real customers by name, and made 23 requests against them using four different techniques.

The short version: all nine homepages opened, but the pages that hold each site's valuable data are a different story. Five deep pages loaded, three came back empty, and one was inconclusive.

Here's what we tested, what happened, why Kasada behaves this way, and what to do if you need the data.

A quick look at the results

• 9 of 9 homepages loaded through URL Scraper, on the first attempt, with no per-site tuning.
• 5 deep pages loaded: an energy plan comparison, a sportsbook odds board, a partner listing, a quote form, and a page on truealliance.com.au.
• 3 deep pages came back empty: property search on realestate.com.au, commercial listings on realcommercial.com.au, and hotel search on hyatt.com.
• 1 result was inconclusive: the product search on crocs.com returned a page with zero results and unrendered template text.
• A commonly cited "Kasada site" wasn't one: Target failed with an explicit PerimeterX block, which is a different vendor entirely.

Opening a homepage and getting the data you actually need are two different problems. The rest of this post shows how we know.

How do you know a site really uses Kasada?

Before testing anything, we needed targets that Kasada itself confirms, not sites a vendor's blog post happens to name. Kasada's own case studies page lists 10+ published case studies. We cross-referenced those against a syndicated case-study aggregator and read the full REA Group PDF, which gave us a confirmed list.

realestate.com.au and realcommercial.com.au (REA Group): confirmed directly, because we read the full case study PDF. REA's own CISO names the reason for deploying Kasada: "defending valuable data against bot attacks and aggressive scraping by commercial research companies and competitors." Keep that sentence in mind, because it explains a lot later.

Crocs, PointsBet, AGL Energy, Flybuys, Hyatt, True Alliance, and Vast Visibility (The Bike Insurer): each confirmed through a named Kasada case study with a named company contact or executive quote, not an unattributed vendor list.

What we left out: Target, Ticketmaster, and several other sites that show up again and again on "Kasada-protected sites" lists. We tested Target directly through a live tool call and it failed with an explicit, named PerimeterX block (HTTP 435), which is a different anti-bot vendor entirely. That isn't a stale claim, it's a wrong one, and it's still sitting in several 2026 guides.

With nine confirmed targets, we could start testing.

How we tested

We ran three passes against the nine sites on 22 October 2026, using Anakin's URL Scraper with a stealth headless browser, plus a Wire catalog check and a multi-step agentic browser run on the hardest target.

• Pass 1 - homepages. Every one of the nine confirmed sites loaded cleanly. Zero blocks.
• Pass 2 - deep, no-login pages. The pages someone would actually want: a property search, a hotel search, a product search, a plan comparison, a quote form. This is where the results split.
• Pass 3 - the hardest result, retested two more ways. We'll get to that after the results.

Homepages were easy. Deep pages weren't.

Pass 1 was straightforward. All nine homepages loaded cleanly through URL Scraper, with no blocks and no manual tuning.

That was encouraging, but a homepage isn't what most people are after. The useful data usually sits deeper. So Pass 2 went there, and this is what came back:

The pages that failed hold the valuable data

Read down the deep-page column. The three outright failures are realestate.com.au's property search, realcommercial.com.au's commercial listings, and hyatt.com's hotel search. Each is its site's core data asset, the exact thing a competitor or a data broker would want to scrape at scale. The successes are mostly adjacent: a sportsbook odds board, an energy plan comparison, a partner list, a quote intake form. Useful pages, but not the crown jewel.

That fits what REA Group's own case study says Kasada is there to stop.

A deep page that did work: AGL's energy plans

For contrast, here's a real call that worked. The energy plan comparison page on agl.com.au returned genuine live pricing, not a block:

POST https://api.anakin.io/v1/url-scraper/scrape
{
  "url": "https://www.agl.com.au/residential/energy/compare-plans",
  "useBrowser": true
}

# Real response excerpt, captured 2026-10-22:
{
  "url": "https://www.agl.com.au/residential/energy/compare-plans",
  "markdown": "# Compare electricity and gas plans\n\n### Electricity\n$1,559 estimated per year...",
  "cached": false,
  "durationMs": 15961
}

The one we couldn't call: Crocs

One result doesn't fit the pattern cleanly. The product search on crocs.com returned a page, but with zero results and a dump of unrendered template placeholders (Size | Size, Color | Color) instead of real product data. The client-side app never fully hydrated. That's consistent with a block that stops execution partway through, but it's also consistent with a malformed query parameter on our end. We're calling it genuinely ambiguous rather than claiming it either way.

Why was realestate.com.au so difficult?

Property search on realestate.com.au is the failure we pushed hardest on. It came back empty in Pass 2, so Pass 3 tried two more approaches.

First, we retested with the correct proxy geography: country: "au" instead of the default "us", since IP-geography mismatch is one of Kasada's own documented scoring signals. Then we ran a full multi-step agentic browser task that mimics session warming: load the homepage, use the real search box, wait for results. Both failed.

The response came back empty after a 33-second wait. No error message, no status code surfaced, no challenge page text, just nothing. That tells us something: it's consistent with a client-side challenge that never resolves, not a clean server-side rejection. It also matches what independent Kasada researchers report running into.

A stealth browser, the right country, and a realistic browsing sequence still weren't enough. To see why, it helps to look at what Kasada actually asks the browser to do.

How does Kasada's KPSDK actually work?

It's not a header you can fake

Most bypass guides describe Kasada as a header you need to fake: send x-kpsdk-ct and x-kpsdk-cd and you're through. That's backwards. Those headers are the output of a computation Kasada forces the browser to actually perform, not a static value you can copy.

A technical reverse-engineering writeup gives the clearest public account. Kasada's client script compiles its fingerprinting and proof-of-work logic into bytecode for a custom virtual machine shipped alongside the page, so it isn't plain JavaScript you can read directly. A separate deobfuscation of a live build found a dispatcher loop, roughly sixty opcode handlers, and a register file behind the obfuscation. The bytecode varies by tenant: the same underlying structure, a different puzzle on every deployment.

What do the CT and CD tokens do?

The token flow has two parts. CT (x-kpsdk-ct) is expensive to compute and reusable for roughly a session's length. It comes from a full fingerprint plus proof-of-work on first load. CD (x-kpsdk-cd) is cheap, single-use, and regenerated for every request, anchored to a server timestamp with a freshness window of a few seconds. That blocks precomputed stockpiles of valid-looking answers.

What does it check inside the browser?

It probes far more than a fingerprint. The kernel.sh writeup describes cross-frame consistency checks, navigator.webdriver getter integrity, deliberately triggered TypeErrors inspected for how they fail rather than whether they fail, and a canvas/GPU check that draws an image and hashes the rendered pixels against what a real consumer GPU would produce. A correct-looking fingerprint API response doesn't help if the thing actually rendering the canvas is software, not hardware. Browser fingerprint signals like these are not unique to Kasada: most anti-bot vendors probe some version of the same canvas/GPU and consistency checks.

One finding matters for anyone automating a real browser rather than a bot library. The writeup found that Playwright's connectOverCDP changes V8 inspector state in a way that alters the shape of JavaScript errors the crash-and-capture probes inspect, and switching to raw CDP reduced failures in their tests. The leak isn't in the browser's observable properties. It's in the automation protocol layer sitting on top of it.

Why do most Kasada bypass guides fall short?

Most of the 2026 guides we read recommend the same toolkit: Nodriver (talks to Chrome directly over the DevTools Protocol, no WebDriver layer to detect), Camoufox (a hardened Firefox build with a different TLS stack than Chrome-based tools), and Patchright, alongside residential proxy rotation and TLS fingerprint matching via JA3/JA4. None of that is wrong as a starting toolkit. What's missing from almost every guide is a results table against sites anyone can independently confirm are actually protected. Most cite success anecdotally, with no benchmark figures.

Our own broader breakdown of anti-bot bypass techniques covers the toolkit side of this in more depth, independent of any single vendor.

The deeper issue is fragility, and the people who build this tooling report the same thing we found. A working configuration can stop working within hours or days as Kasada's bytecode rotates per tenant. Any guide that reports a high pass rate on one specific browser build has a short shelf life. Anyone selling you a durable, one-time fix is selling something that doesn't match how the researchers who reverse-engineer this describe it.

What should you do if you need this data?

If the data is officially available, start there. REA Group, for instance, deployed Kasada specifically to stop scraping like this, so a licensed data partnership or an existing data provider agreement is the durable path, not a rotating cast of stealth browsers racing a polymorphic VM.

If what you need right now is to know when a target's accessibility changes - a new section opens up, a deployment gets relaxed, a page you need stops being blocked - that's a monitoring problem, not a one-time bypass problem. Anakin's Website Monitoring API checks a URL on a schedule and only fires an alert when the result actually changes. Credits are checked upfront but deducted on completion, so a check that doesn't complete doesn't get charged, which matters on a target where failure is the expected default state.

Monitoring isn't bypassing Kasada, and we're not pitching it as that. It answers a different question. And any tool that claims an easy, durable bypass here without showing the actual response it got deserves the same scrutiny we've applied to our own results.

Where this leaves us, and what's next

We're not pretending the deep-page gap is solved. It isn't, not yet. But it isn't nothing either: all nine confirmed Kasada homepages opened cleanly through URL Scraper, on the first attempt, with no manual per-site tuning.

The engineering team is actively working on closing the specific gap this post surfaces: Kasada's deep-page challenge on realestate.com.au, realcommercial.com.au, and hyatt.com. The framing is deliberately narrow. It's three hard pages behind one anti-bot vendor's toughest deployment, not a claim about anti-bot protection in general.

Zoomed out, the picture looks different. URL Scraper and Wire already clear Cloudflare, Akamai, and DataDome-protected sites in most of the cases we see, covering 972 sites and recovering all 43 domains a real customer's Firecrawl setup couldn't reach - see the full comparison. That's separate from this Kasada test, and it isn't evidence that the same approach works on Kasada. Kasada's three hardest pages earn a whole post because they're rare, not because they're typical of what blocks a scraper day to day. For a broader view of Cloudflare- and Akamai-protected targets, see our tested breakdown of scraping APIs against the biggest anti-bot vendors.

Back to where we started: the page that opens in your browser and comes back empty in your scraper. After 23 requests against nine confirmed customers, that gap has a shape. Homepages open. The pages each business protects hardest, its property search and its hotel search, stayed shut. Kasada's design explains why: a polymorphic bytecode VM, timed proof-of-work, GPU-level canvas verification, and protocol-layer leak detection.

Opening a website and getting its data are two different problems. That's more useful to know than another ranked list of stealth browsers, because it tells you where to expect friction before you spend engineering time finding out the hard way.

If you want to track access to a target like this over time, create a monitor on Anakin. The free tier covers 300 credits, with no card required to start.

Frequently Asked Questions

Is there a reliable way to bypass Kasada in 2026?

Not a durable one, for anyone. Independent reverse-engineering and the researchers who build bypass tooling both describe Kasada's bytecode VM as polymorphic per tenant, meaning a working configuration can stop working within hours or days. In our own testing, a stealth headless browser, corrected proxy geography, and a full agentic multi-step browser flow all met the same result against the same confirmed-protected target - consistent with what independent Kasada researchers report elsewhere.

How can I tell if a site is actually protected by Kasada, not another vendor?

Don't trust a scraping-vendor blog's list. Check Kasada's own published case studies, or look for an explicit x-kpsdk-* header or a Kasada-branded challenge page in a real response. In our testing, a commonly-cited "Kasada-protected" site failed with an explicit PerimeterX block instead - a different vendor entirely.

Does Kasada protect an entire site equally, or specific pages?

Our testing suggests protection concentrates on the data that's actually valuable to protect. Across 9 confirmed Kasada customers, every homepage loaded without issue, but the specific search/listing pages holding each business's core data (property listings, hotel inventory) failed consistently across every technique we tried.

What is the KPSDK token system Kasada uses?

KPSDK is Kasada's client-side SDK. It compiles fingerprinting and proof-of-work logic into bytecode for a custom virtual machine embedded in the page, producing two tokens: a session-length CT token from an expensive initial computation, and a cheap, single-use, per-request CD token anchored to a server timestamp with a short freshness window.

What's a better approach than chasing a one-time Kasada bypass?

For data that's officially available through a partnership, use it - it's the durable path. For tracking whether a target's accessibility changes over time, a scheduled monitor like Anakin's Website Monitoring API - checked upfront, deducted only when a check completes - fits the actual shape of the problem better than a bypass technique that degrades on its own timeline.

Sources

1. Bot detection is dead, long live bot detection: reverse-engineering Kasada in an afternoon - kernel.sh
2. Kasada's KPSDK: the 128-bit token, the VM, and the obfuscated bytecode - blog.crawlex.net
3. Kasada Case Studies - kasada.io
4. REA Group Kasada case study (PDF) - get.kasada.io
5. Kasada B2B Case Studies - casestudies.com
6. How to Bypass Kasada Anti-Bot When Web Scraping in 2026 - scrapfly.io
7. Website Monitoring API reference - anakin.io
8. URL Scraper API reference - anakin.io