DEV Community: Yahor Papou

Best Gaming Fraud Prevention Tools in 2026: 10 Options by Risk

Yahor Papou — Sun, 11 Oct 2026 21:55:23 +0000

A welcome bonus can be claimed by several accounts controlled by one player. A valuable game account can be opened from a device its owner has never used. A bot can create accounts faster than a review team can inspect them. Each problem needs a different kind of evidence.

That is why a search for the best gaming fraud prevention tool rarely has one universal answer. Video-game publishers need to protect accounts, in-game purchases and virtual economies. Sportsbooks and online casinos also need to protect promotions, verify players and enforce location rules. A payment tool, a device intelligence platform and a geolocation product solve different parts of that job.

This guide compares ten options by the risk each addresses, the point in the player journey where it works and the work an operator still needs to do. The comparison uses public product documentation reviewed in October 2026. It is an editorial assessment of fit, not a shared hands-on accuracy benchmark.

What to check before choosing a tool

Start with the loss you can actually observe. Is the same person collecting a welcome offer repeatedly? Are stolen cards being used for in-game purchases? Are automated clients creating accounts? Is the operator required to prove a player's physical location? The answer determines what data the tool must see.

Account and bonus abuse: Look for persistent device or visitor identification, links among user accounts and a way to review why accounts were connected. A shared IP alone is weak evidence: families, campuses and mobile carriers can put unrelated players behind one address.
Account takeover: Check what happens when an established account appears on an unfamiliar device or from an unusual location. The signal must arrive early enough to protect the next sensitive action.
Payments and chargebacks: Ask whether the tool sees payment instruments, orders, disputes and game-specific transaction data. A device score alone cannot adjudicate a card dispute.
Bots and automation: Check whether protection runs at the request edge, in the browser, in the app or after an event. These placements affect what the product can stop before a signup or purchase completes.
Regulated iGaming: Verify whether the operator also needs identity and age checks, AML workflows and compliance-grade geolocation. An account-abuse tool does not supply those controls by itself.

The tools below are ordered by fit for account and promotion abuse at the web entry point, followed by specialist products for other risks. A game with several problems may need more than one.

1. ShieldLabs

ShieldLabs identifies returning visitors and links activity across users, devices and IP addresses. More than 300 device and network signals are cross-checked, with 99.9% identification accuracy and 99.9% risk signal detection accuracy. Each scored interaction has a risk score from 0 to 100 and named signals, including VPN, proxy, Tor, anti-detect browser and browser automation detection.

Four High-Risk Events are detected out of the box: multi-accounting, account sharing, impossible travel and account takeover. Each event has Medium or High confidence, separate from the risk score. For an iGaming operator, the most direct application is finding several accounts behind a repeated welcome-bonus claim. For a video-game publisher, the same account-linking layer can surface account farms and returning banned users at web signup or login.

The JavaScript snippet, API and webhooks fit web registration and account flows. ShieldLabs also reports traffic quality by source and campaign, useful when acquisition channels bring farmed signups. It starts with 5,000 free identifications, one time, with no card. Paid plans start at $99 per month.

Best for: Web-based gaming and iGaming teams that need ready-made account-abuse detection and published self-serve pricing. Pair it with a game-client anti-cheat, payment fraud provider, KYC service or regulated geolocation service where those jobs apply.

2. SEON

SEON covers a wider iGaming operations workflow. Its iGaming product combines device and digital-footprint signals with controls for bonus abuse, fake registrations and account takeover. It also offers identity verification, AML and transaction monitoring across the player journey.

That breadth matters to an operator that wants a fraud and compliance stack spanning registration, deposits and withdrawals. It also means the buying decision should be made around the specific modules and data the operator needs, rather than treating every feature in the suite as part of one device check.

Best for: iGaming fraud teams that need account-linking alongside KYC, AML and transaction workflows.

3. SHIELD

SHIELD focuses on persistent device intelligence across web and apps. Its gaming materials cover fake accounts, account takeover, promo abuse and suspicious activity involving game assets. Its public integration guide lists native Android and iOS support as well as Unity, which is relevant when risk must be assessed inside a mobile game rather than only on a website.

The device-first approach helps connect accounts that change email or network. Operators evaluating it should test the device signals at their actual signup, login and in-app checkpoints, and decide which responses belong in the game's own workflow.

Best for: Mobile-first game publishers that need device intelligence in the app and at account checkpoints.

4. EveryMatrix Bonus Guardian

Bonus Guardian is a specialist for promotional abuse in iGaming. It analyzes player activity for bonus exploitation and supports responses such as excluding a player from an offer or holding a withdrawal. Its value is in the promotion workflow itself: the operator can evaluate how a player claims, uses and withdraws against an offer.

There is an important buying constraint. Bonus Guardian is offered to EngageSuite users, so it is a natural shortlist item for an operator already using that stack. A team seeking a standalone web account-identity layer should check integration fit before comparing it with broader fraud platforms.

Best for: EngageSuite operators whose immediate problem is misuse of casino or sportsbook promotions.

5. Xsolla Anti-Fraud

Xsolla's Anti-Fraud System is built around game commerce. It uses payment and in-game parameters to assess suspicious purchases, supports cross-game analysis and provides dispute assistance. That makes it relevant to stolen-card purchases of currency or items, serial payment abuse and chargebacks.

Its evidence comes from the purchase and the game's economy. If the pressing problem is a player opening many accounts before making a payment, pair transaction screening with an account and device layer earlier in the journey.

Best for: Video-game publishers protecting in-game purchases, payment acceptance and disputes.

6. GeoComply Core

For a licensed sportsbook or online casino, proving where a player is can be a requirement, not merely a fraud signal. GeoComply Core verifies location using device and network data and checks for location spoofing. Its gaming product also assesses device integrity and activity such as location jumping, proxy betting and account sharing.

That is a distinct job from estimating a visitor's location from an IP address. An operator entering a restricted jurisdiction should evaluate geolocation accuracy, coverage and regulatory requirements directly, alongside its account-abuse controls.

Best for: Regulated betting and casino operators that need compliance-grade geolocation and location-fraud detection.

7. Sift

Sift assesses fraud across account creation, login, account activity, payments and post-transaction events. Its iGaming offering addresses multi-account bonus abuse, account takeover and risky transactions, with review and automation workflows for fraud teams.

It is a fit when the operator wants to bring player, device and transaction activity into one investigation and decision process. Compare its operational workflow with the size of your fraud team and the data you can supply at each event.

Best for: Larger iGaming operations that need joined-up account, payment and review workflows.

8. Sumsub

Sumsub brings identity and age verification, KYC and AML checks, plus gaming-specific fraud and player-risk workflows. Its iGaming solution also covers transaction monitoring, bonus abuse and responsible-gaming processes. These functions matter where the operator must establish who a player is and whether they are eligible to play, deposit or withdraw.

Sumsub also offers device and account-linkage signals, so it should be evaluated for repeat registrations as well as document checks. When bonus claims are the issue, test whether the operator can connect the verified identity, the device and the promotion history in one review.

Best for: Regulated gaming operators that need player verification and compliance workflows together with fraud controls.

9. Fingerprint

Fingerprint assigns a persistent visitor ID to a browser or device and supplies Smart Signals for bot activity, VPN use and browser tampering. Its web and mobile integrations make it a useful foundation for recognizing a device that returns with a new account or arrives at a sensitive login.

The operator still needs a clear policy for what a repeated device means. Fingerprint publishes implementation guides for linking visitor IDs to accounts and building responses on top of them. That flexibility suits an engineering team that wants to own the account graph and enforcement workflow.

Best for: Developer teams that want device identification and risk signals as inputs to their own fraud system.

10. DataDome Bot Protect

DataDome specializes in detecting and mitigating automated requests to websites, apps and APIs. It can act at the edge, before a bot-driven signup or credential-stuffing request reaches the application. This makes it a strong candidate when attack volume and automation are the immediate problem.

Bot mitigation and account-linking answer different questions. A real person can operate several bonus accounts without looking like a bot, while an automated client can create thousands of accounts without ever reaching a payment screen. Test the layer that matches the abuse you see.

Best for: Gaming platforms facing automated signup, login and API abuse at scale.

A practical shortlist by problem

One player, many accounts or repeated welcome offers: Begin with ShieldLabs, SEON or SHIELD. Add Bonus Guardian if promotion usage inside an EngageSuite operation is the central issue.
Stolen payment methods, virtual-goods purchases or chargebacks: Evaluate Xsolla or Sift alongside account signals.
Licensed gambling across restricted locations: Put GeoComply on the compliance shortlist and Sumsub on the identity and age-verification shortlist.
Automated registrations or credential stuffing: Evaluate DataDome at the request edge, then use device and account signals to find the activity that gets through.
A team building its own fraud graph: Fingerprint supplies durable visitor and device inputs; the team defines the linking and response workflow.

Before buying, run the shortlisted products against the same real account journeys: a legitimate shared household, a returning player after clearing cookies, several bonus claims from linked accounts, an unfamiliar device on a valued account and a burst of automated signups. Ask for the raw reason behind each result. A tool that catches abuse but cannot explain its false positives will be hard to operate.

Four mistakes that make a fraud-tool pilot misleading

Calling every linked account abuse. One household can share a device, and some games allow alternate accounts. Review the account relationship alongside offer claims, timing and the game's rules before taking action.
Testing only known bad players. Run legitimate households, shared networks and returning players through the same pilot. The rate of unnecessary challenges and manual reviews belongs in the buying decision.
Expecting one score to cover every stage. An account score does not see a card dispute unless payment data is supplied. A payment screen does not establish whether a new player claimed the same welcome offer under an earlier account.
Treating account links as proof of gameplay collusion. Device and account connections can identify a group worth reviewing. Demonstrating coordinated play or wagering also requires game or betting events.

Frequently asked questions

Which types of fraud should gaming platforms check first?

Start with the points where the platform loses value: duplicate accounts and repeated offers at signup, account takeover at login, automated account creation, and fraudulent purchases or chargebacks. A regulated sportsbook or casino must also check player identity, age and location. In-game cheating and collusion need game or betting telemetry beyond an account-level check.

Are gaming fraud and iGaming fraud the same thing?

They overlap at accounts and payments, but their requirements differ. A video-game publisher may care most about account theft, item markets and in-game purchase fraud. A sportsbook or casino also needs promotion controls, identity and age verification, location compliance and checks around deposits and withdrawals.

Does device intelligence replace game-client anti-cheat?

No. Device intelligence links activity at account and transaction checkpoints. A game-client anti-cheat examines behavior and integrity inside the game. The two can share context, but one does not perform the other's job.

What is the first signal to inspect for bonus abuse?

Look for several accounts connected to the same persistent visitor or device, then examine the offer claims and the risk signals around them. A single shared IP does not establish abuse. Linked accounts plus repeated claims make a stronger case for review.

What is multi-accounting in gaming?

Multi-accounting means one player operates more than one account. It can be permitted, such as an alternate game account, or abusive, such as opening fresh accounts to reclaim a welcome bonus or evade a ban. Account linkage identifies the relationship; the game's rules and the player's activity establish whether the behavior violates them.

How long does a gaming fraud tool take to integrate?

There is no useful universal number. A web snippet may return a first device signal quickly, while a production workflow also needs account identifiers, event timing, review rules and false-positive checks. Payments, KYC and regulated geolocation need their own data and checkpoints. Ask each vendor to demonstrate the first useful result in your actual signup, login or purchase flow.

Gaming fraud prevention works best when the evidence matches the decision. Start with the player action that costs you money or trust, choose the tool that can observe it, and test it on legitimate players as well as abusive patterns.

For web account and bonus abuse, ShieldLabs offers 5,000 free identifications, one time.

Fingerprinting vs cookies: what actually differs, and what developers should build

Yahor Papou — Fri, 25 Sep 2026 11:26:10 +0000

Cookies store data locally on a device and stay visible to anyone who opens their browser settings. Fingerprinting builds a server-side identifier from dozens of device and browser signals, and it is far harder to detect, delete, or opt out of. The practical stakes follow directly from that split: cookies fall under user control and standard consent banners, while fingerprinting resists ordinary privacy tools and draws closer regulatory scrutiny because it can persist through the exact actions people take to stop tracking.

TL;DR:

Fingerprinting can recognize returning visitors across weeks or months by analyzing stable device traits, even after cookies are cleared or private browsing is used.

Unlike cookies, fingerprinting signals are stored on the server and regenerate with each visit, making them invisible and resistant to user control or opt-out.

Under privacy law, any method that reads device signals, including fingerprinting, often requires the same consent as non-essential cookies, especially when identifiers are persistent.

Using a rotating-salt, cookieless approach can provide accurate daily visitor counts without persistent tracking, but it limits long-term recognition capabilities.

Enterprise-level fingerprinting gathers 300+ device and network signals, such as VPN use, proxies, and automation detection, delivering 99.9% identification accuracy for fraud prevention in challenging conditions.

Cookies vs Fingerprinting: A Quick Comparison

Both methods try to answer the same question, whether a visitor has been here before, but they get there through completely different mechanics. The table below breaks down the six dimensions that matter most when you're evaluating returning user recognition or trying to understand what's tracking you.

Storage: Cookies live in a local file on the user's device; fingerprints are computed and stored server-side.
Persistence: Cookies expire or get cleared; fingerprints regenerate from stable hardware and browser traits.
User control: Cookies can be viewed, blocked, or deleted in browser settings; fingerprints offer no equivalent on/off switch.
Detectability: Cookies are transparent by design; fingerprinting scripts run quietly in the background.
Consent requirements: Non-essential cookies generally require opt-in consent; fingerprinting often falls under the same legal obligation despite storing nothing locally.
Typical uses: Cookies handle logins, carts, and preferences; fingerprinting supports fraud detection, security, and analytics that need to survive a cleared cache.

The practical takeaway: if you can see it and delete it, it's probably a cookie. If it keeps recognizing you anyway, it's probably not.

How Do Cookies Work?

A cookie is a small text file a website asks your browser to store, containing a piece of data like a session ID or a saved preference. That's the entire mechanism. No hashing, no hardware signals, just a file sitting in your browser's storage that gets sent back to the server on every request.

Cookies split into two useful categories. Session cookies disappear the moment you close your browser tab. They're what keeps you logged into a shopping cart while you browse. Persistent cookies stick around for a set expiration date, sometimes days, sometimes years, which is how a site remembers your language preference three weeks later. There's a second split that matters more for privacy: first-party cookies come from the site you're actually visiting, while third-party cookies get set by a different domain (usually an ad network) embedded in that page, and it's third-party cookies that built the ad-retargeting industry of the 2010s.

Every major browser gives you direct visibility into this system. Chrome, Firefox, and Edge all let you inspect, block, or wipe cookies through their settings menus, and clearing your cookies genuinely breaks the recognition, at least for cookie-based tracking. That user-facing control is precisely why cookies sit differently in privacy law than fingerprinting does: the mechanism is visible, so the consent model built around it, opt-in banners for non-essential cookies, actually works as intended.

The browser landscape has also been actively closing this door. Safari's Intelligent Tracking Prevention has capped and restricted third-party cookie lifespans for years, and the broader industry shift away from third-party cookies has pushed advertisers and analytics vendors toward alternative identification methods, fingerprinting chief among them. That migration is a big part of why fingerprinting vs cookies has become a live debate rather than a settled question: as one door closes, another quietly opens.

One nuance that trips people up: not every cookie needs consent. Strictly necessary cookies, the ones that keep a login session alive or remember items in a cart, are generally exempt from opt-in requirements under most cookie law frameworks. It's the non-essential ones, the analytics and advertising cookies, that trigger the consent banners you click through daily.

How Does Browser Fingerprinting Work?

Fingerprinting skips local storage entirely and instead builds an identifier out of characteristics your device already broadcasts. A script running on a page can quietly collect your screen resolution, installed fonts, GPU rendering quirks through canvas and WebGL tests, browser plugins, time zone, language settings, and even how your device's audio stack processes a test signal. None of these signals alone is unique. Combined, dozens of them narrow down to a device profile that's often unique among millions of visitors, according to Surveillance Self-Defense's fingerprinting explainer.

That combined profile gets hashed into a single identifier and stored on the server, not on your device. There's no file to open, no setting to toggle off, because the "fingerprint" isn't a thing sitting on your machine waiting to be deleted. It's a calculation the server performs every time you show up, based on traits your hardware and browser configuration hand over automatically just by loading a page.

This is exactly why clearing cookies or switching to private/incognito mode doesn't reliably stop it. A Princeton CITP technical brief explains that fingerprint-derived identifiers regenerate instantly after you wipe local storage, because the underlying hardware and browser traits never changed. Private browsing mode blocks cookies from persisting past the session, but it doesn't alter your screen resolution, your installed fonts, or your GPU's rendering signature. The fingerprint comes right back, identical to before.

That persistence is a double-edged property. Used for cross-site ad profiling without disclosure, it's the kind of stealthy tracking that's drawn increasing public attention, including reporting on the rise of fingerprinting as sites lean on it to replace fading cookie-based methods. Used for fraud detection and account security, the same underlying technique serves a legitimate purpose: recognizing that the device attempting a login or a signup has shown up before under a different account, even after clearing its cookies. The signal is identical. The application, and the disclosure around it, is what separates responsible use from covert profiling.

What Are the Key Differences That Actually Matter?

Six dimensions separate these two methods, and each one carries a different practical consequence depending on whether you're a privacy-conscious reader or a product team building recognition logic.

Storage location is the foundational split. Cookies sit in a file on the user's own device, which means the user technically owns the storage medium. Fingerprints live entirely on the tracker's server, computed from signals the device exposes but never actually written down locally. That's the core reason clearing your browser data deletes one and does nothing to the other.

Persistence follows directly from storage. A cookie has an expiration date, or vanishes the moment the browser wipes it. A fingerprint has no expiration because it's recalculated fresh each visit from traits that rarely change, screen size, installed fonts, GPU behavior. Engineering-wise, fingerprinting is built for stability across months; cookies are built to expire.

User control and detectability diverge sharply too. Every browser ships a visible cookie manager. No browser ships an equivalent "fingerprint manager," because there's nothing local to manage. You can see a cookie in your settings. You generally can't see that a fingerprinting script just ran, unless you're using specialized detection tools.

Consent and legal treatment, somewhat counterintuitively, don't follow the same split. Regulators have made clear that the mechanism doesn't determine the legal obligation, the effect does. That means a technique with zero local storage can still trigger the same consent requirements as a cookie, a point worth sitting with before assuming "cookieless" automatically means "compliant."

Typical uses tend to diverge by design intent rather than capability. Cookies dominate session management, shopping carts, and login persistence, the bread-and-butter of everyday web functionality. Fingerprinting shows up where a business needs recognition that survives a cleared cache: fraud detection, bot mitigation, and account security, where the whole point is catching someone who's actively trying to look like a new visitor.

Picture three scenarios. A returning customer logging into a loyalty account: a cookie handles that fine, and login state makes it airtight regardless. A user attempting account takeover after wiping their browser data: cookies tell you nothing, because they were cleared along with everything else, but device signals persist and can flag the same hardware attempting entry under a new identity. Measuring unique visitors for analytics: cookies inflate the count every time someone clears their cache, while fingerprinting (used carefully) can hold a more accurate number, though at a real privacy cost if that identifier isn't time-limited.

What Do Privacy Regulators Actually Focus On?

Regulators don't care what you call the technique. Article 5(3) of the ePrivacy Directive, the EU rule most commonly cited, applies to storing or accessing information on a user's terminal equipment, and Article 29 Working Party's Opinion 9/2014 makes clear the trigger is that technical act, not the word "cookie" specifically. Later EDPB guidance built on that same reading.

That framing directly covers fingerprinting. Because a fingerprinting script reads dozens of device characteristics off the terminal equipment to build its identifier, that reading act falls within the same scope as setting a cookie, even though nothing gets written to local storage. The practical result: many uses of fingerprinting need the same consent treatment as non-essential cookies, and a site can't dodge that obligation just by swapping the underlying mechanism.

There's a real exception, though, and it matters. Genuinely privacy-preserving "cookieless" analytics can sidestep consent requirements, but only when the identifier is engineered to expire, not persist. Gizmo Analytics describes an approach that hashes IP address and user agent together with a salt that rotates daily, producing a short-lived identifier good for counting same-day unique visitors without ever creating a stable, cross-day profile. Rotate the salt, and yesterday's identifier stops matching today's, by design. That's a meaningfully different architecture from fingerprinting aimed at long-term stability, and regulators generally treat design intent, expire versus persist, as the dividing line.

For product teams, a workable compliance checklist looks like this: disclose what signals you collect and why, limit how long any derived identifier stays valid, offer a real opt-out where the law requires one, and document the specific purpose behind persistent recognition rather than defaulting to "just in case." Obfuscating a persistent identifier to dodge a consent banner is exactly the move regulators have flagged as indefensible.

How Can You Reduce Tracking, and What Should Developers Build Instead?

If you're trying to limit exposure as an individual, start with realistic expectations. Browser extensions like uBlock Origin and Privacy Badger block a meaningful share of tracking scripts, and browsers with built-in anti-fingerprinting measures (Firefox's Enhanced Tracking Protection and Brave's fingerprinting randomization among them) add friction that basic scripts can't easily defeat. Private browsing mode still has real value for blocking cookie persistence and hiding local history, but don't expect it to stop fingerprinting; the underlying device traits it reads don't change just because you opened an incognito window.

Use a browser with built-in anti-fingerprinting protection rather than relying on default settings.
Install a script-blocking extension and keep it updated, since fingerprinting techniques evolve.
Treat private mode as cookie protection, not fingerprint protection, and adjust expectations accordingly.
Check periodically whether a site's cookie banner actually covers fingerprinting scripts, since many don't disclose it clearly.

For developers weighing how to build recognition into a product, the choice comes down to how much persistence the use case actually justifies. Kitbase's cookieless analytics explainer lays out the tradeoff plainly: rotating-salt architectures give you accurate same-day metrics and skip the consent overhead, but they sacrifice the ability to recognize the same anonymous visitor across weeks. If your product genuinely needs that longer-horizon recognition, fraud detection is the clearest example, a durable signal like login state or a disclosed device identifier is the more honest architecture than quietly reaching for fingerprinting to fill the gap.

Pro Tip: If your only goal is counting unique visitors without profiling anyone, a rotating-salt, cookieless approach is almost always the better privacy-preserving choice. Save persistent device recognition for cases where the business need, like stopping repeat fraud, genuinely requires it and you can document why.

What Does Enterprise-Level Fingerprinting Look Like in Practice?

Consumer-grade fingerprinting scripts typically lean on a handful of signals: canvas rendering, fonts, screen size. Enterprise fraud detection operates on a different scale entirely. ShieldLabs draws on 300+ device and network signals, covering risk signals like VPNs, proxies, Tor, iCloud Private Relay, datacenter IP ranges, anti-detect browser detection, and automation traffic, interpreted through a mix of deterministic rules and AI.

The identification layer is built for persistence specifically because fraud actors count on the opposite: cleared cookies, incognito sessions, rotated IPs, months of gaps between attempts. The platform recognizes a returning visitor with 99.9% identification accuracy across exactly those conditions. Every score arrives with the underlying signals attached, so fraud or trust teams can see the reasons behind risk scores rather than relying on an opaque number. The service supplies the score and the signals behind it; teams choose the action for each case: flag it, restrict it, or escalate it for review. Teams that want the signal-level detail can dig into how device fingerprinting works or browse the broader device fingerprinting resource library.

Why Transparency Should Beat Convenience Every Time

The fingerprinting vs cookies debate keeps getting framed as a technical question when it's really a disclosure question. Nothing about server-side identification is inherently worse than a cookie, the harm comes entirely from doing it quietly. A team that documents exactly what signals it reads, limits how long any derived identifier stays valid, and builds a consent gate around genuinely non-essential tracking has nothing to hide and no reason to obscure the mechanism.

My honest read: most of the "cookieless is automatically compliant" confusion in this space comes from vendors marketing convenience as virtue. Persistence should be a deliberate, justified choice, not a default setting nobody examined.

Yahor Papou, CMO at ShieldLabs

Get Signal-Level Visitor Recognition Without the Enterprise Sales Call

Enterprise fraud teams have had access to deep device and network signals for years, usually behind an annual contract and a sales conversation. This platform provides similar depth, including anti-detect browser detection, proxy and VPN scoring, and ready-made detection of multi-accounting, account sharing, impossible travel and account takeover, available self-serve with published pricing from day one. Every risk score comes with the signals that produced it, so teams see why a user was flagged and choose the action for each case rather than relying on a black-box verdict.

Setup runs through a single JavaScript snippet, roughly five minutes to the first signal, with guides for React, Next.js, Vue, and WordPress, plus server-side SDKs for Node.js, Python, Go, and PHP. The Free plan covers 5,000 identifications, one time, with no card required, enough to test recognition accuracy against your own traffic before committing to anything. From there, paid plans (Starter, Growth, and Scale) start from 79 USD a month billed yearly, or 99 USD month to month, with per-identification pricing decreasing as volume increases. Check current pricing and plan details to see which tier fits your traffic volume.

Frequently asked questions

Is It Better to Accept or Reject Cookies?

Rejecting non-essential cookies is generally the safer privacy choice, since it limits third-party tracking and ad profiling without breaking core site functionality. Strictly necessary cookies, like login sessions, typically load regardless of your choice because they're exempt from the consent requirement.

Which Browser Is Best for Avoiding Fingerprinting?

Browsers with built-in anti-fingerprinting protection, such as Firefox's Enhanced Tracking Protection and Brave's fingerprinting randomization, reduce how reliably a device can be uniquely identified. No mainstream browser eliminates fingerprinting entirely, since the underlying signals it reads are largely unavoidable byproducts of normal web browsing.

Which Is Safer, Password or Fingerprint Authentication?

This question usually refers to biometric fingerprint login, not browser fingerprinting, and the two are unrelated technologies. Biometric fingerprint authentication is generally considered more resistant to casual compromise than passwords, since it can't be guessed or reused across sites the way a weak password can.

Can You Be Tracked Through Cookies?

Yes, cookies can track you across a session or across visits, particularly third-party cookies shared across multiple sites for ad targeting. Unlike fingerprinting, cookie tracking is visible and reversible: clearing your browser's cookies removes the identifier entirely, according to EFF's fingerprinting explainer, which contrasts that reversibility with fingerprinting's persistence.

How Much Does ShieldLabs Cost for Fraud Detection?

ShieldLabs offers a Free plan covering 5,000 identifications, one time, with no card required, followed by paid tiers at 79, 319, and 799 USD per month billed yearly (99, 399, and 999 USD month to month) depending on volume, all listed on the pricing page.

Sources

Originally published on the ShieldLabs blog.

Headless browser detection before JS runs: JA4, WebGL and CDP timing

Yahor Papou — Fri, 25 Sep 2026 11:26:03 +0000

Headless browsers are detectable with high confidence when independent signals line up. A mismatched TLS/JA4 fingerprint, a SwiftShader-rendered canvas hash, and a lingering CDP artifact rarely occur together in a genuine session. No single check is reliable on its own, which is why the right approach treats detection as evidence, aggregated into a risk score, rather than a pass/fail gate on any one property.

TL;DR:

Combining network fingerprints, JavaScript checks, and CDP artifacts offers the most reliable detection of headless browsers with minimal false positives.

WebGL renderer strings, especially those indicating software rendering like SwiftShader, are among the strongest signals for headless sessions.

Behavioral patterns such as uniform request animation frame intervals and unnatural mouse movements help distinguish bots from human users over time.

Network fingerprints like JA4 TLS and HTTP/2 frame ordering detect automation before scripts load, making them high-confidence early signals.

Using a risk score that aggregates multiple signals helps prevent false positives, allowing proportionate responses based on the overall confidence level.

What Layers Produce the Strongest Headless Browser Detection Signals?

Every automated session leaks evidence at several distinct layers, and knowing where each signal originates changes how much you should trust it. Network fingerprints arrive before a single line of page JavaScript executes. Runtime properties and rendering artifacts show up only once the page loads. Behavioral signals accumulate over the course of a session.

Grouping checks this way matters because some are passive and server-side, while others require active in-page instrumentation:

Pre-render network layer: TLS client hello structure, HTTP/2 frame ordering, and connection metadata, all collectible before rendering starts.
JavaScript runtime layer: navigator properties, permissions, plugin lists, and client hints.
Rendering and GPU layer: WebGL renderer strings and canvas output.
Control-channel layer: residue left by the Chrome DevTools Protocol and similar automation interfaces.
Behavioral layer: timing cadence, mouse and scroll entropy, and interaction patterns over time.

A session that fails one check in isolation might just be a privacy-hardened browser or an unusual configuration. A session that fails checks across three or four layers simultaneously is a much stronger case. Layering checks this way is also what keeps false positives down, since no individual signal has to carry the full weight of a decision.

Why Do JavaScript-Level Checks and Navigator Properties Still Matter?

navigator.webdriver is the oldest and most obvious tell in automated browsing sessions. WebDriver-controlled sessions set this flag to true by default, and while stealth plugins routinely patch it to false or delete it, the patch itself often becomes the giveaway. A genuine Chrome property has a native getter defined on Navigator.prototype. A patched one frequently shows up as an own property on the instance, or a getter whose toString() output doesn't match V8's native function signature.

That distinction is checkable directly:

Compare Object.getOwnPropertyDescriptor(Navigator.prototype, 'webdriver') against what you'd expect from a stock browser build.
Call navigator.webdriver.toString.toString() and check whether it returns "function toString() { [native code] }" or something a patch script generated.
Walk the prototype chain with Object.getPrototypeOf() to confirm the property lives where it should, not injected further down the chain.

Beyond the webdriver flag, plugin and MIME-type lists are worth checking for internal consistency. A real Chrome installation reports a specific, small set of built-in plugins (PDF viewer entries, primarily) with matching MIME types. Headless configurations frequently report an empty plugin array, or a mismatched one that doesn't correspond to the reported Chrome version.

Client hints add another contradiction surface. Compare the legacy navigator.userAgent string against navigator.userAgentData (where available) and against feature detection results. A user agent claiming Chrome 120 on Windows that lacks expected Windows-specific font rendering or codec support is inconsistent in a way that's cheap to catch and expensive to fully patch. Language and locale mismatches between navigator.languages, the Accept-Language header, and Intl.DateTimeFormat().resolvedOptions().timeZone round out the picture.

How Do CDP Artifacts Reveal Automation After JS Patches?

The Chrome DevTools Protocol is what tools like Puppeteer and Playwright use to drive a browser, and it leaves marks that survive most JavaScript-level stealth patching. This matters because a growing share of anti-detection tooling focuses entirely on faking navigator properties while leaving the control channel untouched.

Common CDP residue includes:

Injected global variables left behind by automation frameworks, sometimes named predictably (__playwright, __puppeteer, or similar patterns depending on the tool version).
Stack traces that reference CDP-internal frames rather than a clean native call path when errors are thrown deliberately inside a probe function.
Event-listener counts or ordering that differ from a human-driven session, since CDP commands often attach or manipulate listeners as a side effect.

The most resilient of these signals is timing jitter. Every CDP command is a round trip between the controlling process and the browser, and that round trip introduces latency that doesn't exist in native user interaction. CDP roundtrips and their control-channel residue are difficult to eliminate entirely, even in sessions where every obvious JS flag has been scrubbed.

Pro Tip: Measure the delay between dispatching a synthetic requestAnimationFrame callback and its execution across several hundred frames. A CDP-driven session shows a measurably different jitter distribution than a native render loop, even when every navigator property looks clean.

Do WebGL Renderer Strings Really Expose Headless Sessions?

Yes, and it's one of the highest-confidence checks available. Headless environments frequently lack access to real GPU hardware, so they fall back to software rendering, most commonly Google's SwiftShader implementation. That fallback is visible directly through the WebGL API.

Here's how to read it:

Get a WebGL context and call getExtension('WEBGL_debug_renderer_info').
Query gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL) and inspect the returned string.
Flag strings containing "SwiftShader," "llvmpipe," or other known software-rendering identifiers, since real consumer hardware almost never reports these.

WebGL rendering anomalies tied to software renderers are among the most reliable headless indicators available, largely because faking a convincing GPU renderer string while actually running on software rendering requires spoofing the entire rendering pipeline, not just one string value.

Canvas fingerprinting adds a second layer of confidence on top of the renderer string. When you draw the same shapes, text, and gradients to a canvas element and hash the pixel output, software renderers tend to produce hashes that cluster tightly together across different machines, because they're all running the same rendering math instead of real, varied GPU hardware. A deeper look at how WebGL fingerprinting works covers the hashing approach in more detail. Pairing the canvas hash with frame-timing measurements, since software rendering tends to produce more uniform frame times than hardware acceleration, cuts down on false positives from legitimate low-end devices.

What Timing and Behavioral Signals Separate Bots From People?

Rendering and network checks catch a lot, but timing and interaction patterns catch what's left. The core idea is that human interaction with a page has irregularities that scripted interaction doesn't bother to fake, because faking them convincingly is expensive.

Useful signals in this category:

requestAnimationFrame cadence: capture a sequence of performance.now() timestamps across consecutive rAF callbacks; native rendering loops show natural variance tied to display refresh rate, while some automation frameworks show suspiciously uniform intervals.
Mouse movement entropy: real cursor paths have acceleration curves and micro-corrections; synthetic mouse events dispatched via CDP or dispatchEvent tend to move in straight lines or teleport between coordinates.
Scroll behavior: genuine scrolling has variable velocity and momentum; programmatic scrolling often jumps to exact pixel offsets instantly.
Interaction timing relative to page load: a click registering within milliseconds of DOM ready is far more common in scripts than in people.

The key design decision is window length. Short-window checks (a few seconds) catch obvious automation fast but produce more false positives from legitimate power users or accessibility tooling. Longer-window checks, aggregated over a full session, are more accurate but slower to act on. Most production setups run both: a fast heuristic for early flagging, and a longer behavioral profile that adjusts the risk score as more data accumulates.

How Do TLS and HTTP/2 Fingerprints Catch Bots Before JS Runs?

Network-level fingerprinting catches automation before a single page script executes, which makes it one of the most valuable early-warning signals available. The two most useful techniques here are JA3/JA4 TLS fingerprinting and HTTP/2 frame-level analysis.

JA3/JA4 fingerprints are derived from the TLS ClientHello message: the cipher suites offered, extensions included, and their ordering. TLS and HTTP/2 settings are critical pre-rendering signals that expose mismatches between a claimed User-Agent and the actual network stack. A request claiming to be Chrome 120 but presenting a ClientHello structure that matches Python's requests library or a headless Chromium build with a stripped-down cipher list is lying somewhere, and JA4 makes that mismatch easier to catch than its predecessor. A closer look at JA4 fingerprinting and how it improves on JA3 explains the underlying structure.
HTTP/2 frame ordering and SETTINGS values offer a second, independent check. Real browsers send SETTINGS frames in a specific, engine-determined order with particular initial values for window size and header table size. Many scripting libraries and headless configurations use HTTP/2 implementations with different defaults, and that difference is visible at the frame level without touching application content.

Both techniques share a critical advantage: they operate underneath naive user-agent spoofing entirely. Changing the User-Agent header is trivial. Reproducing an authentic browser's exact TLS handshake and HTTP/2 settings profile requires either running that actual browser engine or a purpose-built TLS stack that mimics it precisely, which is a meaningfully higher bar. Background on how TLS fingerprinting and JA3/JA4 work covers the collection method in more depth.

Pro Tip: Log JA4 fingerprints server-side alongside the User-Agent header for every request during a testing window, then flag any User-Agent that maps to more than one distinct JA4 value across your traffic. Legitimate browser versions produce a narrow, predictable set of fingerprints; scripted traffic often doesn't.

Where Do Codec, Permission, and Font Checks Catch Impersonation?

Capability mismatches are cheap contradiction checks that catch impersonation attempts that got the obvious properties right but missed the details underneath.

HTMLMediaElement.canPlayType() returns different codec support depending on the actual browser build and OS. A session claiming to be Chrome on Windows that reports unusual codec support (or none) for formats Chrome handles natively is inconsistent with its own claimed identity.
The Permissions API (navigator.permissions.query()) should behave logically: querying camera or microphone permission on a headless session with no media devices attached often returns states that don't match what a real device with those peripherals would report.
Font enumeration and glyph rendering differ subtly across operating systems and browser builds. A page that measures text rendering width for a specific font list can catch a session claiming macOS while rendering fonts consistent with a Linux container, which is exactly the kind of environment many headless deployments run in.

None of these checks are decisive alone, but each adds one more contradiction to a growing case.

How Should You Test and Validate Detection Signals?

Building detection logic without a repeatable test harness is a good way to ship checks that either miss real automation or flag legitimate users. A structured validation process avoids both failure modes.

Build a local comparison harness. Run the same page against a real headed browser and its headless counterpart (Puppeteer, Playwright, Selenium) on identical hardware, and log every signal side by side: canvas hash, UNMASKED_RENDERER_WEBGL value, navigator descriptors, and TLS fingerprint.
Correlate network and JS-layer signals server-side. Since JA4 fingerprints arrive before any page script runs, tag each session server-side at connection time, then join that tag against the JS-layer signals captured later in the request lifecycle to build a labeled dataset.
Maintain a regression suite. Testing both headed and headless runs while capturing canvas hashes, renderer strings, and TLS fingerprints gives you a baseline to re-run whenever a browser engine or automation library updates, since minor version bumps regularly shift these values.
Keep dataset hygiene tight. Separate true positives, false positives, and ambiguous cases explicitly, and re-evaluate thresholds against fresh traffic on a fixed schedule rather than assuming static thresholds age well.

How Do You Turn Signals Into a Risk Score and a Response?

Blocking on any single failed check is a fast way to lock out legitimate users running privacy tools, unusual hardware, or accessibility software. A risk score built from multiple independent signals reduces false positives compared with treating any one check as a binary gate.

Practical patterns worth building in:

Weight network-layer and rendering-layer signals more heavily than any single JS property, since they're harder to spoof convincingly.
Use graduated responses tied to score bands: passive monitoring at low risk, silent friction (extra verification steps, slower response times) at medium risk, and hard challenges or manual review only at high risk.
Log which specific checks fired and their raw values, not just a final score, so the rule can be audited and re-tuned later.
Revisit thresholds regularly against fresh traffic, since automation tooling and stealth patches evolve continuously.

Pro Tip: Never let a single high-weight signal override the aggregate score in isolation. A legitimate user on a locked-down corporate browser can trip one or two checks; a real automated session trips several at once. The pattern across signals is what should drive the response, not any one flag.

How Does a Fraud Detection Platform Turn Raw Signals Into a Score?

A detection layer built specifically for this problem consolidates the checks above into a single, explainable output instead of leaving every team to build and maintain its own signal collection pipeline from scratch. ShieldLabs collects 300+ device and network signals per visit and returns them alongside a risk score rather than a black-box verdict.

The relevant signal categories map directly onto what's covered here:

Network-layer signals, including TLS/JA4 fingerprints and connection metadata, surfaced through network intelligence.
Device and runtime signals, covering rendering artifacts, navigator inconsistencies, and automation residue, surfaced through device intelligence.
Persistent identification logic that recognizes a returning device across sessions even when cookies are cleared or IPs rotate.

Integration follows a two-part model: a JavaScript snippet collects client-side signals, and a server-side SDK (available for Node.js, Python, Go, and PHP) returns the risk score and signals to your backend. You choose the action for each case: review a session in the Suspicious band (30–59), or require stronger proof of identity in the Dangerous band (60–100), with the score and its underlying signals always visible rather than hidden inside an opaque decision.

That auditability matters for tuning over time. Every score arrives with the specific signals that produced it, so a team can trace a false positive back to the exact check that fired and adjust from there instead of guessing at what changed.

What Are the Ethical Limits of Headless Browser Detection?

Detection logic touches the same signals used for legitimate accessibility tooling, automated testing, and privacy-conscious browsing, which makes proportionality a real design constraint, not an afterthought.

Automated testing frameworks, uptime monitors, and accessibility tools running headless browsers are not fraud. A detection system that treats every headless signal as hostile will flag QA pipelines, monitoring services, and screen-reader-adjacent tooling right alongside scraping bots and account takeover attempts. Building in an allowlist path for known-good automated traffic, verified through means other than the browser signals themselves, avoids that collateral damage.

Privacy is the second constraint. Canvas fingerprinting, WebGL renderer queries, and behavioral tracking are the same techniques used for cross-site tracking, and running them without any disclosure invites both regulatory scrutiny and reasonable user objection. Collecting these signals for fraud and abuse prevention is a different purpose than ad tracking, and that distinction should show up in how the data is retained, who can access it, and how long it's kept, not just in a privacy policy nobody reads.

Proportional response matters as much as accurate detection. A medium-confidence signal should trigger a step-up in friction, not an automatic ban. Reserving hard blocks for high-confidence, multi-signal cases keeps the false-positive cost low, and keeps the system defensible if a legitimate user ever asks why they were flagged.

Where Does Headless Browser Detection Actually Get Used?

The theory matters, but the operational value shows up in specific, recurring scenarios across industries.

Account abuse prevention. Free-trial abuse and multi-accounting schemes frequently rely on scripted signups run through headless browsers to create dozens or hundreds of accounts quickly. Network and rendering signals catch the automation layer even when each account uses a different email and IP.

Ad fraud detection. Automated traffic generating fake ad impressions or clicks is a persistent problem for publishers and ad networks, and headless browsers are a common tool for generating that traffic at scale because they're cheap to run in bulk on cloud infrastructure.

Scraping and content protection. E-commerce sites monitoring for competitor price scraping, and media sites protecting paywalled content, both rely on the same layered signals to distinguish scripted scraping tools from real visitors browsing normally.

Checkout and payment flows. Fintech and e-commerce platforms watch for headless sessions attempting to test stolen card numbers or exploit promo codes at volume, since manual testing at that speed isn't feasible for a person.

Loyalty and referral programs. Gaming and iGaming platforms in particular see scripted sessions farming referral bonuses or loyalty points across large numbers of fabricated accounts, often behind the same connection.

In every one of these cases, the detection layer flags the risky session, and you choose the action for each case, whether that's a manual review queue, a temporary hold, or simply excluding that traffic from analytics.

Which Automation Frameworks Are Easiest to Detect?

Not all automation tools leave the same footprint, and the differences matter when you're deciding where to focus detection effort.

Selenium tends to be the easiest to catch. Its WebDriver protocol implementation sets navigator.webdriver reliably, and older Selenium versions in particular leave characteristic artifacts that detection scripts have targeted for years, making it a well-documented baseline case.

Puppeteer, which drives Chromium directly through CDP, patches many JS-level checks more thoroughly out of the box, but that's precisely why CDP-layer timing and control-channel artifacts matter more for catching it. Its default headless mode also tends to surface SwiftShader rendering unless specifically configured otherwise.

Playwright supports multiple browser engines (Chromium, Firefox, WebKit) and has more mature built-in stealth behavior than either of the other two by default, which pushes detection further toward network fingerprints and behavioral signals rather than obvious JS properties.

None of these frameworks is inherently more or less "detectable" in some fixed sense; detectability depends heavily on configuration, the stealth plugins layered on top, and which signal categories a given detection setup actually checks. A team relying solely on navigator.webdriver will catch unmodified Selenium easily and miss a well-configured Playwright session entirely. A team combining network fingerprints, rendering checks, and CDP timing analysis closes most of that gap regardless of which framework is driving the browser underneath.

Practical trade-offs when treating headless signals as evidence

Every detection rule trades sensitivity against user impact, and there's no threshold that eliminates that trade-off entirely. Push too aggressively on any single signal and you'll catch privacy-conscious users, QA pipelines, and accessibility tooling alongside real abuse. Tune too conservatively and scripted traffic slips through untouched.

The practical answer is iteration, not a perfect starting configuration. Run new checks in a monitoring-only mode before they ever affect a live decision, watch what they flag, and adjust weights against real traffic before tightening enforcement. Detection signals age, too, as browser engines and automation libraries update, so a rule set that worked well six months ago deserves a second look now.

Yahor Papou, CMO at ShieldLabs

Get the Signals and Risk Score Without Building the Detection Stack

Building and maintaining every check covered here, TLS fingerprinting, WebGL analysis, CDP timing, behavioral profiling, is a real engineering investment most teams don't have the bandwidth to sustain long term. A detection platform can collect 300+ device and network signals per visit, including anti-detect browser detection and automated browser traffic, and return them alongside a risk score, so you choose the action for each case. Scores split traffic into three bands, Trusted (0–29), Suspicious (30–59) and Dangerous (60–100), with the specific signals behind each score fully visible rather than hidden in a black box.

Setup can run through a JavaScript snippet on the frontend and server-side SDKs for Node.js, Python, Go, and PHP, typically reaching a first signal within about five minutes. ShieldLabs offers a one-time free tier of 5,000 identifications with no card required, which can be enough room to test detection accuracy against your own traffic before committing to a paid plan. Start by exploring the identification product and running it against a real traffic sample.

Sources

Originally published on the ShieldLabs blog.

10 browser fingerprinting techniques explained

Yahor Papou — Wed, 16 Sep 2026 20:50:57 +0000

Browser fingerprinting is the foundation of device intelligence: the way a site recognizes the same visitor without a cookie. Browser fingerprinting techniques are the individual methods a site uses to read attributes of a browser, each one probing a different surface, and combine them into an identifier that recognizes the same visitor again. No single attribute is unique; the power is in the combination. A landmark study by the Electronic Frontier Foundation, published in the 2010 Privacy Enhancing Technologies Symposium proceedings, found that a browser fingerprint carried enough distinguishing detail to single out roughly 84 percent of browsers in its sample.

The toolkit has grown from a handful of HTTP headers to a layered read across the graphics stack, the audio engine, and the network itself. The consistent pattern is that the attributes a browser can fake in JavaScript are the weak ones, and the techniques that reach down to the real hardware and the connection are the ones that hold up under a tool built to defeat them. This guide walks through the main techniques behind browser fingerprinting, what each one reads, and how stable each is.

Key takeaways

A browser fingerprint is built from many techniques at once. Each reads one attribute, and combined they carry enough distinguishing detail to recognize a returning visitor without a cookie.
The strongest techniques read what the browser cannot easily hide: how the device renders graphics (canvas, WebGL), processes audio, and negotiates a connection (TLS, network).
Declared attributes like the user agent are easy to spoof, so they add little on their own. The render-and-hardware techniques are what make a fingerprint stable.
Anti-detect browsers fake these attributes per profile, but faking many layers consistently is hard, so the contradictions between them are their own detection signal.

What are browser fingerprinting techniques?

Browser fingerprinting techniques are the individual methods a website uses to read attributes of a visitor's browser, with each method probing a different surface such as graphics rendering, audio processing, installed fonts, or the network connection. No single attribute is unique on its own, but together they carry enough distinguishing detail to recognize the same browser, and the device behind it, again without a cookie. These are the methods behind browser fingerprinting.

How browser fingerprinting works

Browser fingerprinting works by collecting attributes that vary from one device to the next, then combining them into a single identifier. Each attribute on its own is shared by many people; together they narrow the field until the combination is, in most cases, unique. The detail that makes it work is that much of this data is exposed automatically through standard browser APIs, so a script can read it in milliseconds without any permission prompt.

The techniques split into two families. Declared attributes are values the browser simply reports, like the user agent or the language, and they are trivial to change. Derived attributes are produced by asking the browser or device to do something, render an image, process an audio signal, negotiate a connection, and reading the result. Derived attributes are what give a fingerprint its staying power, because they reflect the real hardware and software underneath rather than a string the user can edit.

The main browser fingerprinting techniques

The techniques below are listed roughly from the most stable to the most easily changed. A real fingerprint reads many of them at once. Most of them run inside the browser, canvas, WebGL, audio, fonts, and the declared attributes, while TLS and WebRTC read the layer underneath, the connection and the network, which is why they are harder to fake and pull double duty for anonymity detection. In practice a detection system reads across all of these together.

Technique	What it reads	How stable
Canvas fingerprinting	A hash of how the device renders text and graphics to a hidden canvas	High
WebGL fingerprinting	The GPU and graphics driver, read from a rendered 3D scene	High
Audio fingerprinting	Tiny differences in how the device's audio stack processes a generated signal	High
TLS fingerprinting (JA3/JA4)	The exact shape of the TLS handshake the browser sends	High
WebRTC	A local or real IP address the browser can expose, even behind a VPN	Medium
Font fingerprinting	Which fonts are installed and how they render	Medium
Hardware attributes	CPU cores, device memory, touch points, sensors	Medium
Media device fingerprinting	How many media devices are connected and of what kind (full labels need camera or mic permission)	Low
Screen, timezone, language	Resolution, color depth, timezone offset, locale	Medium
User agent and client hints	The declared browser, version, and operating system	Low

Canvas fingerprinting

Canvas fingerprinting asks the browser to draw text and shapes to an off-screen HTML canvas, then reads the pixel data back and hashes it. Because the result depends on the GPU, the graphics driver, the operating system's font rendering, and anti-aliasing, two devices almost never produce the same hash. It is one of the most reliable techniques because the user cannot easily change how their hardware renders, which is why canvas fingerprinting carries so much weight in a combined read.

WebGL fingerprinting

WebGL fingerprinting is the 3D cousin of canvas. A script renders a scene through the WebGL API and reads back both the rendered output and the reported GPU vendor and renderer strings. By exposing the graphics hardware directly, WebGL fingerprinting stays stable per device and is hard to spoof convincingly.

Audio fingerprinting

Audio fingerprinting uses the Web Audio API to generate a sound signal, process it through the device's audio stack, and measure the output. The tiny variations introduced by the hardware and the audio processing produce a stable value that differs between devices, even when nothing is actually played out loud. This kind of audio fingerprinting is a different thing from the music recognition that shares the name.

TLS fingerprinting (JA3/JA4)

TLS fingerprinting reads the connection itself rather than anything in the page. When a browser opens an encrypted connection, the order and contents of the TLS handshake it sends are characteristic of the client software. Methods like JA3 and the newer JA4 summarize that handshake into a value, which is powerful because it is sent over the network and a page script cannot rewrite it. It is the technique that most often catches a browser lying about what it is, and the JA4 fingerprint is how that handshake becomes a value you can compare.

To see how far that goes, run browsers configured to spoof their identity through a combined read, and the TLS handshake is the layer that gives them away most reliably. A profile can rewrite its user agent in seconds, but the handshake it actually negotiates still matches the client software underneath, so the declared browser and the connection stop agreeing. JA4, released in 2023, made that handshake easier to reduce to a single comparable value, which is why a contradiction between it and the declared user agent is such a dependable tell.

WebRTC

WebRTC is a browser feature for real-time audio and video, and while setting up a connection it can reveal a local network address, and sometimes the real public one, even when the visitor sits behind a VPN or proxy. That makes it less a source of device distinguishing detail and more a way to notice a connection that is hiding its origin. It is why WebRTC matters more for anonymity detection, surfacing a real address that contradicts the declared one, than for telling two ordinary devices apart.

Font fingerprinting

Font fingerprinting detects which fonts are installed by measuring how sample text renders, since a missing font falls back to a default with different dimensions. The set of installed fonts reflects the operating system and the software a person has added, which makes it a useful medium-stability signal.

Hardware and device attributes

A browser also exposes hardware hints: the number of logical CPU cores, an approximate amount of device memory, the maximum number of simultaneous touch points, and, with permission, motion and orientation sensors. The set of supported browser features and APIs adds a few more bits the same way. Older techniques read the battery level and charging state too, though browsers have since restricted that one specifically because it was being used to track people. None is unique alone, but together they add distinguishing detail and tend to stay constant for a given device.

Media device fingerprinting

Media device fingerprinting reads the list of media inputs and outputs the browser reports through the media devices API: the microphones, cameras, and audio outputs attached to the machine. It captures nothing from them, only how many are connected and of what kind. The full list, with each device's label and ID, is only exposed once the visitor has granted camera or microphone access, so on its own this technique is a weak, supporting signal rather than a primary one. Where it does apply, the set of devices stays fairly consistent for a given machine and is awkward to fake convincingly across a fleet of fake profiles.

Screen, timezone, and language

Screen resolution and color depth, the timezone offset, and the language and locale are all read directly. They are moderately stable and useful mostly as corroboration, and a mismatch between them, a timezone that disagrees with the declared locale, is itself a tell.

User agent and client hints

The user agent string and the newer client hints report the browser, its version, and the operating system. They are the easiest attributes to spoof, so on their own they add almost no distinguishing detail, but when they disagree with what the render and TLS techniques reveal, that disagreement is a detection signal.

How unique and stable is a fingerprint?

A fingerprint's strength comes from distinguishing detail: how much each attribute narrows the field of possible devices. The EFF's early research found most browsers were unique within its sample. In 2018, a study of around two million fingerprints, published in the Web Conference proceedings, found only about 33 percent were unique, because common phone models share very similar fingerprints. The practical reality sits in between: on desktop, a full fingerprint is usually distinctive; on mobile, it is weaker on its own and leans more on the network and behavioral layers.

Stability is the other half. Fingerprints drift as browsers update, drivers change, and fonts are added, so a resilient system does not expect an exact match every time. It scores how much of the fingerprint agrees and tolerates small changes, which is also what separates a returning real user from an assembled profile that is too clean or internally contradictory.

Can browser fingerprinting be blocked?

Browser fingerprinting can be resisted but not fully blocked, and the trade-offs are real. Privacy browsers and extensions add noise to canvas and audio readings, block known scripts, or make a device look like many others, and an anti-detect browser goes further by spoofing a full set of attributes per profile. Each of these changes some surfaces, but covering every technique consistently is hard, and the act of covering them, a too-uniform fingerprint, an injected-noise canvas that changes on every read, or a TLS handshake that disagrees with the declared browser, becomes its own signal. That cat-and-mouse plays out in full when a session runs an anti-detect browser.

How browser fingerprinting works without a cookie

Browser fingerprinting works without a cookie, and that is the point. A cookie is a value the site writes into the browser, so the visitor can clear it, switch to a private window, or move to a fresh browser and the link is gone. A browser fingerprint is not written anywhere; it is derived on the fly from the attributes the techniques above read, so the same browser produces the same identifier on the next visit even after cookies are cleared. That is why it survives the resets a fresh email and a private window are meant to provide.

Fingerprinting does not replace cookies so much as complement them. A first-party cookie is a fast, reliable way to recognize a returning visitor who has not cleared anything, and the fingerprint is the layer underneath that still holds when the cookie is gone. Reading both together gives a steadier recognition than either one alone. That complement matters even though the third-party cookie did not disappear on the timeline many expected: in April 2025, Google confirmed it would not phase out third-party cookies in Chrome after all, keeping its existing cookie-choice approach, so cookieless recognition is a resilient companion to cookies rather than a scramble to replace them.

How browser fingerprinting helps detect fraud

Browser fingerprinting helps detect fraud because most online abuse depends on one person looking like many different people. Multi-accounting, free-trial farming, fake signups, and account takeover all rely on creating a fresh-looking visitor for each attempt, usually by clearing cookies, switching browsers, or rotating IPs. A browser fingerprint cuts through that, because the same device keeps producing the same identifier no matter how many fresh emails and new IPs sit on top of it. Linking those attempts back to one device is what turns a wall of separate-looking accounts into a recognizable pattern.

The combination of techniques is also a fraud signal in its own right. A real browser produces attributes that agree with each other: the declared user agent matches what the render and TLS techniques reveal, the timezone fits the locale, the network looks like a residential connection. A tool built to fake a visitor has to keep all of those layers consistent at once, and the moment they can contradict each other, a TLS handshake that disagrees with the declared browser, a risk signal that surfaces a real address behind a VPN, that disagreement is the tell. So fingerprinting helps detect fraud two ways at once: it links repeat attempts to one device, and it flags the inconsistencies that mark an assembled identity.

Recognizing returning visitors with ShieldLabs

ShieldLabs turns device and browser signals into a stable device identifier through one JavaScript snippet that recognizes a returning visitor even after cleared cookies and a rotated IP. The identifier is derived from the combination of signals, which is what makes it survive the resets a fresh email and a new IP are meant to provide, so your team can link repeat fraud and abuse attempts back to one device.

Around that identifier, each visit returns a risk score from 0 to 100 with the named signals behind it, including the risk signals, a VPN, anonymous proxy, datacenter connection, or anti-detect browser, that surface when what a visitor presents and the underlying signals contradict each other. The API and webhooks deliver the risk score and named risk signals, while four High-Risk Events, multi-accounting, account sharing, impossible travel and account takeover, are detected directly in the analytics dashboard, API and webhooks. Because the read happens in the background from data the browser already exposes, it adds no friction for a real visitor, and ShieldLabs helps block fraudulent and abusive traffic.

Sources

Eckersley, Peter (Electronic Frontier Foundation): How Unique Is Your Web Browser? (PETS, 2010)
Wikipedia: Device fingerprint
MDN Web Docs: Canvas API
Gómez-Boix, Laperdrix, Baudry: Hiding in the Crowd: An Analysis of the Effectiveness of Browser Fingerprinting at Large Scale (WWW, 2018)
Google: The Privacy Sandbox: Next steps (2025)

Free-trial abuse vs API-key abuse vs rate limiting: which layer stops what

Yahor Papou — Wed, 16 Sep 2026 13:58:48 +0000

A self-serve AI product gets a surprise five-figure compute bill, and the incident channel calls it "API abuse." Sometimes that is right. Often the real cause sits one layer upstream, at signup, where one person quietly farmed a hundred free-trial accounts and every one of them minted a valid key. In 2025, Stripe found that AI startups with self-serve sign-ups and direct API access saw 10x more attempted abuse than enterprise AI solutions, and a lot of that pain comes from blaming the wrong layer. Free-trial abuse, API-key abuse, and rate limiting get treated as one thing. They are three problems, on three layers, with three owners, and the fix for one does almost nothing for the others.

Key takeaways

Free-trial abuse is an identity problem at signup: one user opening many accounts to claim free credits. You stop it before a key is ever issued.
API-key abuse is a usage problem after a key exists: a key, often a leaked legitimate one, called at a volume or in a pattern it should not be.
Rate limiting and spend caps are ceilings, not an identity check. They cap any single key, but they do not know that one person is behind a hundred of them.
The layers complement each other. Identity scoring keeps farmed accounts from minting keys; gateway limits contain the damage of any key that slips through or leaks later.
A CAPTCHA gates obvious bots at the form. It does not catch a human operator running many real-looking signups, and it is a different control from device-and-network identity.

The three problems people blame for one bill

These three get conflated because they all end in the same place, a bigger-than-expected bill or a degraded service, but they start in different places. Naming where each one starts is the whole game, because the cheapest fix lives at the layer where the problem begins, not where the symptom shows up.

Free-trial abuse starts at the signup form, before any account or key exists. One user creates many accounts to claim the free credits each new account gets.
API-key abuse starts after a key is issued: a valid key gets shared, leaked, or pointed at the API in a way it was never meant for.
Rate limiting is not a problem at all; it is the gateway control that caps how hard any one key or org can hit you. It contains damage, but it does not identify who is behind the traffic.

Conflating them is how a team ends up with a gap: they tighten rate limits and rotate keys after a bad week, feel safer, and never notice that the farmed accounts minting those keys are still arriving at the front door untouched.

Free-trial abuse vs API-key abuse vs rate limiting at a glance

Here is the boundary in one view. Read down each column to see that these are genuinely different problems, not three names for one.

	Free-trial (signup) abuse	API-key abuse	Rate limiting and spend caps
What it is	One user opens many accounts to claim free credits repeatedly	A key, often a leaked or shared legitimate one, used at the wrong volume or pattern	A ceiling on how many calls or how much spend any one key or org is allowed
When it happens	At signup, before the account or key exists	After a key is issued, during usage	Continuously, as a guardrail on every key
What is behind it	A human (sometimes automated) farming identities; the device repeats while the email and IP rotate	A leaked credential, a scraper, or a legitimate key pushed past its intent	Nothing; it is your own enforcement, not an adversary
The layer	Signup identity	Key usage	Gateway
Who owns the fix	Identity scoring at registration	Key rotation, scoping, per-key monitoring	Your API gateway or proxy
What it costs you if missed	Compute burned across a hundred farmed accounts, plus polluted growth metrics	A single key running away with your budget or exfiltrating data	Without it, one key can drain the whole bill

What is free-trial abuse?

Free-trial abuse is one user creating many accounts to claim the same free offer more than once, scored and stopped at the registration before any credits or keys are provisioned. It hides because the user changes the surface details, a fresh email, a new IP, a cleared cookie, while the device and network behind the accounts repeat. An email check or an IP rule never sees that repetition; reading the device does.

We measured this by rebuilding a signup the way a farmer does, rotating a new email, a fresh IP, and an emptied cookie on each pass, and the device underneath kept pointing at the same identifier every time. The surface details are meant to be disposable; the device is the part that repeats. That gap only widened in 2020, when Safari began blocking third-party cookies by default, leaving a cookie an even weaker anchor for a signup than the device beneath it.

This is the only one of the three layers that is about who is signing up rather than what a key is doing. The advantage is timing: scoring the registration is far cheaper than chasing the compute after a hundred trials are already calling the model. The signals, the credit-gating, and the economics of how to prevent free-trial abuse at an AI company all turn on that timing; the point here is just where it sits: upstream of the key, at identity.

What is API-key abuse?

API-key abuse is a valid key being used at a volume, from a place, or in a pattern it was never meant for, and it lives entirely after the key is issued. The key might be a leaked secret committed to a public repo, a shared credential passed around a team, or a legitimate key repointed at scraping the model's output. Whatever the source, the control surface is the key itself, and the standard moves are the gateway's:

Scope and rotate keys. Short-lived, narrowly scoped keys limit the blast radius of any one that leaks. Broken authentication is one of the most common API risks for a reason, and it is squarely an API-security concern, not a signup one.
Per-key spend caps. A hard ceiling on spend per key and per org means no single credential, abused or not, can run away with your budget. The OWASP API Security Top 10 calls the missing version of this "unrestricted resource consumption."
Anomaly monitoring on usage. Watch for a key whose call volume, geography, or endpoint mix suddenly changes, the signature of a credential that has left its owner's hands.

None of this reads the human at the front door, and it does not need to. API-key abuse is downstream of identity. By the time a key exists, the farmed-account question was already answered, or missed, one layer up.

What is rate limiting (and spend caps)?

Rate limiting caps how many requests a key or org can make in a window, and spend caps cap how much it can cost; both are essential guardrails, and neither knows who is behind the traffic. They are about volume, not identity. A rate limiter will happily throttle one key at a thousand requests a minute, which is exactly what you want when a single credential goes rogue.

The gap is structural: a rate limit applies per key. The free-trial farmer's whole technique is to spread the load across a hundred keys, each one comfortably under the limit. A hundred accounts each making polite, well-behaved calls is invisible to a per-key ceiling, because no individual key ever misbehaves. Spend caps have the same blind spot. They stop one key from draining the budget; they do nothing about a hundred keys each spending a small, allowed amount that sums to the same loss. Rate limiting contains the runaway-key problem and leaves the farmed-account problem completely open. That is not a flaw in rate limiting; it is just a different layer.

Where CAPTCHA and bot-gating fit

A CAPTCHA sits at the signup form and tries to separate humans from scripts, which makes it a bot control, not an identity one. It raises the cost of fully automated, headless signup floods, and for that narrow job it helps. Two things it does not do: it does not stop a human operator, or a lightly automated one driving a real browser, from completing many real-looking signups, and it does not tell you that two solved-CAPTCHA signups trace back to one machine. CAPTCHA asks "is this a bot?"; the identity layer asks "have we seen this device before?". They answer different questions, and a serious farming operation passes the first while failing the second.

Which layer stops what: the honest map

Put together, the picture is simple and the layers do not substitute for each other:

Signup identity catches the farmed account before a key is minted. It is the cheapest place to act, because nothing has been provisioned yet.
Key scoping, rotation, and monitoring contain a key after it exists, whether it was farmed past the identity layer or leaked later.
Rate limits and spend caps are the backstop that keeps any single key, abused or not, from running away with the bill.
CAPTCHA thins out crude automation at the form, and leaves the human-operated farm for the identity layer.

A team that only hardens the gateway, more rate limits, tighter key scopes, is defending the second and third layers while the first stays open. A team that only scores signups stops the farm but still needs ceilings for the key that leaks next week. The two halves are complementary by design.

Where ShieldLabs fits, and where it does not

ShieldLabs reads exactly one of these layers: the signup-identity one. You add a JavaScript snippet to your signup or trial-activation page, and on the first visit it returns a risk score from 0 to 100 with the risk signals and persistent identification behind it, before a single credit or key is provisioned. When a "new" signup traces back to a device you have already seen, that linkage is the farmed-account tell a fresh email is meant to hide.

To be plain about scope: ShieldLabs scores the signup on a 0 to 100 risk score, names the risk signals that fired, and directly detects multi-accounting, so your team can keep farmed accounts from minting keys in the first place and the layer downstream has less to contain. Key usage monitoring, secret rotation, and spend-cap enforcement are your gateway's job, and they should stay there. You read the risk score and named risk signals through the API and webhooks and decide, by your own rules, whether to gate credits, ask for a verification step, or let a clean signup through. It complements the gateway. The same identity layer carries into new-account fraud prevention and free-trial abuse prevention.

Ready to close the signup-identity gap?

Install the ShieldLabs JavaScript snippet and risk-score every trial signup for linked accounts and risk signals in about five minutes, free for the first 5,000 identifications.

Start Free

Originally published on the ShieldLabs blog.

JA4 fingerprinting explained: how it improves on JA3, and what it actually identifies

Yahor Papou — Tue, 15 Sep 2026 13:03:29 +0000

JA4 fingerprinting identifies the software behind a connection, a browser, a script, or an automation tool, by reading the TLS Client Hello it sends and condensing that handshake into a short, readable string. It is FoxIO's 2023 successor to JA3, and it exists for one reason: JA3 stopped working. JA3, the old way of fingerprinting a TLS client, broke when the browsers it watched started shuffling their own handshake. After Chrome began randomizing the order of its TLS extensions in 2023, JA3, which hashed those extensions in the order they arrived, produced a different value on almost every connection, so the fingerprint that was supposed to recognize a client recognized nothing. JA4, released the same year by FoxIO, is the answer: it sorts the values instead of trusting their order, stays human-readable, and covers more than just TLS. This guide explains what JA4 is, how it improves on JA3, and the part most write-ups skip, what it actually identifies and what it does not.

Key takeaways

JA4 is a network fingerprint that identifies the software stack behind a connection, a browser, a script, or a tool, from the TLS Client Hello it sends, before any page code runs.
It replaced JA3 because JA3 was order-sensitive: once browsers randomized their TLS extension order, JA3's hash changed on every connection. JA4 sorts the values, so reordering no longer breaks the match.
A JA4 fingerprint is readable, not just a hash. Its parts spell out the TLS version, the cipher and extension makeup, and the application protocol, and JA4 is one of a family (JA4+) that also covers HTTP, TCP, and the server side.
JA4 identifies a client type, not a person or a unique device. Everyone on the same browser and operating system can share one JA4, so it is a corroborating signal, never an identifier on its own.
In fraud detection its value is the contradiction: a request that claims to be one browser but whose JA4 says it is a script or a tool is the tell, read at the network layer.

What is JA4 fingerprinting?

JA4 fingerprinting is a method of identifying the software behind a connection by reading the TLS Client Hello, the first, unencrypted message a client sends when it opens a secure connection, and condensing its characteristics into a short, standardized string. Because different software, a Chrome browser, a Python script, a Go HTTP library, builds that handshake differently, the resulting JA4 string is characteristic of the client type that produced it. It is the successor to JA3, created by FoxIO, the firm founded by JA3's original author John Althouse, and published as an open specification, and it sits at the network and transport layer rather than in the browser. It is the JA4 piece of TLS fingerprinting more broadly.

The reason it reads the Client Hello is that this message is sent in the clear, before encryption begins, so a server can fingerprint the client without decrypting anything. What the fingerprint captures is configuration, the TLS version offered, the list of cipher suites, the extensions, and the application protocols, which together form a signature of the software, not the user.

How JA4 improves on JA3

JA3, introduced in 2017 by John Althouse and colleagues at Salesforce, hashed the Client Hello fields in the exact order the client sent them and reduced the result to a single opaque value. That worked until the order stopped being stable. When browsers began permuting their TLS extensions on purpose, a change Chrome rolled out in 2023, the same browser produced a different JA3 on every connection, and the fingerprint collapsed. JA4 fixes this by sorting the values before it builds the fingerprint, so a harmless reordering produces the same JA4. It also keeps the fingerprint readable instead of hashing everything into one blob, and it extends beyond TLS into a whole family of fingerprints. The differences at a glance:

	JA3	JA4
Introduced	2017	2023
Output	one opaque MD5 hash	a readable, multi-part string
Extension order	order-sensitive, breaks on reordering	sorts the values, survives reordering
Readability	none, just a hash	parts you can read (TLS version, cipher and extension counts, ALPN)
Scope	the TLS client only	a suite covering TLS, the server, HTTP, TCP, and more

The practical upshot is resilience. JA3 was easy to defeat by accident, every browser that randomized its handshake broke it, and easy to defeat on purpose. JA4 raises the bar on both, which is why detection tooling moved to it.

The JA4 string format

A JA4 fingerprint is written in readable parts, often shown as a_b_c, in a compact multi-part shape (the two trailing hashes are 12 characters each, while the readable first part varies). Each part answers a different question:

Part a captures the protocol and transport, the TLS version, whether the connection is over TCP or QUIC, the presence of a server name, and the application protocol negotiated via ALPN (Application-Layer Protocol Negotiation), so t13 reads as TLS 1.3.
Part b summarizes the cipher suites the client offered, as a count plus a sorted hash, so reordering the same ciphers does not change it.
Part c does the same for the extensions and the signature algorithms.

A complete JA4 looks like t13d1516h2_8daaf6152771_02713d6af862: the t13d reads as TLS 1.3 over TCP with a server name present, the digits 1516 count the offered cipher suites (15) and extensions (16), h2 is the negotiated HTTP/2 preference, and the two trailing blocks are the sorted cipher and extension hashes. JA4 also ignores GREASE values, the deliberately random entries a browser adds to its handshake to keep the protocol extensible (defined in RFC 8701), so that padding never shifts the fingerprint.

Because the parts are separate and legible, an analyst can match on the whole string or on a single segment, and can read roughly what a client is from the fingerprint alone rather than looking it up in a table. Because a JA4 is readable and portable, common fingerprints are catalogued in open databases such as JA4DB and can be read directly in tools like Wireshark, so a value seen in your logs can be identified rather than reverse-engineered.

The JA4+ suite: more than TLS

JA4 is the TLS-client member of a larger family called JA4+, a set of fingerprints for different layers of a connection. The ones that come up most:

JA4 fingerprints the TLS client from its Client Hello.
JA4S fingerprints the server's response, the Server Hello.
JA4H fingerprints the HTTP request, including the order of headers and the presence of things like an Accept-Language.
JA4T fingerprints the TCP characteristics, such as window size, which can hint at the operating system or a proxy in the path.
JA4X fingerprints an X.509 certificate, and JA4SSH covers SSH sessions.

Read together, the suite describes a connection from several angles at once, which is what makes a contradiction between layers, a TLS stack that does not match the HTTP behavior, so informative. Recent research pushes the same multi-layer idea further: a 2026 arXiv preprint, On the Internet, Nobody Knows You're an LLM Bot, combines network, HTTP, and browser-level fingerprints to unmask automated web agents, exactly the kind of cross-layer read where a transport-layer fingerprint that disagrees with the browser above it becomes the tell.

What JA4 can and cannot tell you

This is the part that matters most and is the easiest to get wrong. A JA4 fingerprint identifies a client's software stack, not a person and not a unique device. Everyone running the same browser version on the same operating system tends to produce the same JA4, so the fingerprint groups clients by type rather than singling anyone out. It is explicitly not designed to be unique, and there are real edge cases where it is not even stable for one client: Safari, for instance, can reuse a prior session through a TLS extension and present a different fingerprint on the next connection.

That is not a flaw to hide; it is the right way to use the signal. JA4 tells you what kind of client is connecting, with high confidence and almost no cost, and it tells you that server-side before a single line of page code runs. What it does not do is tell you who the visitor is or pin them to one machine. Treated as a corroborating signal rather than an identifier, it is genuinely useful. Treated as a unique ID, it produces false matches and misses.

JA4 in fraud detection

For threat hunters and web application firewalls, JA4 is mostly about grouping malicious traffic and rate-limiting clients that rotate IPs. For fraud and abuse detection the more useful read is narrower: the contradiction between what a client claims to be and what its JA4 says it is. A request can set a user-agent header that says Chrome on Windows, but the user-agent is just a string the client chooses, while the JA4 is produced by the actual TLS library underneath. When the header says one thing and the TLS stack says a scripting library or an automation framework, the mismatch is hard to fake and easy to read. A missing or unusual application protocol value, where a real browser would normally negotiate HTTP/2, points the same way. The reverse holds too: dedicated TLS-impersonation tools can forge a JA4 that matches a real browser, so a clean, matching fingerprint is not proof of a genuine client, only the absence of an obvious mismatch, which is one more reason to read JA4 as corroboration rather than identity.

In testing, we ran requests that set a user-agent header claiming Chrome on Windows and the network layer disagreed: the TLS stack underneath matched a scripting library or automation framework, not the browser named in the header. The header is a string the client picks; the JA4 is produced by the library actually opening the connection, which is far harder to align. This gap became more useful in 2023, when Chrome began randomizing its TLS extension order and JA4's sorted, readable format kept the fingerprint stable through the change.

That makes JA4 a strong corroborating signal for automated abuse and for anti-detect browser setups, which spoof the browser-side fingerprint but often miss the transport layer underneath. It is read alongside the rest of the session rather than acted on alone, because a shared JA4 is normal: the goal is to catch the session whose layers disagree, not to treat a common fingerprint as guilt.

Detecting spoofed clients with ShieldLabs

ShieldLabs reads network signals as one input among many, never as a standalone verdict. The network signals behind a request are cross-checked against the declared browser, the risk signals on the connection, and the rest of the session, so a client whose network layer disagrees with what it claims to be raises the read rather than passing on a header alone.

ShieldLabs scores the session, the device, and the network, and names the signals behind a risk score from 0 to 100. You read that score and the named signals through the API and webhooks and decide, by your own rules, what a contradiction is worth. The broader technique behind these signals is covered in TLS fingerprinting and the wider set of browser fingerprinting techniques.

Sources

FoxIO: JA4+ Network Fingerprinting specification
Amazon Web Services: JA4Fingerprint (AWS WAF reference)
IETF: RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
IETF: RFC 8701: Applying GREASE to TLS Extensibility
Fayolle, Bouhenniche, Pélissier, Laperdrix, Maurice, Rudametkin: On the Internet, Nobody Knows You're an LLM Bot: Unmasking Web Agents with Multi-Layer Fingerprinting (arXiv preprint, 2026)
Wikipedia: Transport Layer Security

FAQ

What is a JA4 fingerprint?

A JA4 fingerprint is a short, readable string that identifies the software stack behind a connection, derived from the TLS Client Hello a client sends when it opens a secure connection. Because a browser, a script, and a tool each build that handshake differently, the JA4 string is characteristic of the client type. It is created by FoxIO as the successor to JA3 and is written in a compact, multi-part format that a person can read directly.

Is JA4 better than JA3?

For most purposes, yes. JA3 hashed the TLS Client Hello in the order the client sent it, so once browsers began randomizing their extension order, the same browser produced a different JA3 on every connection and the fingerprint stopped working. JA4 sorts the values before fingerprinting, so reordering does not break it, and it is human-readable and covers more protocols. JA3 still appears in older tooling, but JA4 is the more resilient successor.

Is a JA4 fingerprint unique?

No. A JA4 fingerprint identifies a client's software stack, not an individual device or person, so everyone using the same browser version and operating system tends to share the same JA4. Some clients are not even stable across connections, for example Safari can present a different fingerprint when it reuses a prior TLS session. That is why JA4 is best used as a corroborating signal weighed with others, not as a unique identifier.

What is the difference between JA3 and JA4?

JA3 produces a single opaque hash of the TLS Client Hello in the order it arrived, which made it break when clients reordered their extensions. JA4 produces a readable, multi-part string and sorts the values so reordering does not change it, and it is part of the JA4+ family that also fingerprints HTTP, TCP, and the server side. In short, JA4 is more resilient, more readable, and broader in scope than JA3.

How does ShieldLabs use network signals?

ShieldLabs reads network signals as one input among many. They are cross-checked against the declared browser and the rest of the session and folded into a risk score, never acted on as a standalone verdict. ShieldLabs scores the session and hands the result to your own rules, and the free tier covers your first 5,000 identifications.

Originally published on the ShieldLabs blog.

Residential proxy detection: why home IPs are the hardest to catch, and how detection actually works

Yahor Papou — Tue, 15 Sep 2026 13:03:19 +0000

A residential proxy hands an attacker a real home IP address, with a clean reputation, in the right city, that can change on every single request. Every defense built around the address itself, reputation lists, datacenter ranges, the old rule of one IP per account, quietly waves it through. That is what makes residential proxies the hardest masked traffic to catch, and it is also the clue to catching them: residential proxy detection is not an IP problem at all. This guide explains what a residential proxy is, where the home IPs actually come from, why IP-based checks miss them, and how detection works when the address is no help.

Key takeaways

A residential proxy routes traffic through a real ISP-assigned home IP, so to a website it looks like an ordinary customer rather than an intermediary.
The home IPs are sourced from real consumer devices, usually enrolled through bundled apps, bandwidth-sharing schemes, or compromised hardware, often without the owner paying attention.
Because the address is a genuine home connection, IP reputation, blocklists, and ASN checks, the tools that catch datacenter proxies, mostly fail on residential ones.
Detection works by reading everything except the address: rapid IP rotation, many accounts behind one home gateway, the device that stays the same as the IPs change, and network contradictions like a datacenter TLS stack or a leaked real IP.
Residential proxies are the hardest case, so no single signal is reliable. Detection corroborates several, treats a contradiction as a risk signal rather than proof, and leaves the decision to you.

What is a residential proxy?

A residential proxy is an intermediary that routes a user's traffic through an IP address that a consumer Internet Service Provider assigned to a real home. Because the request arrives from a genuine household connection, the destination site sees the homeowner's ISP and location instead of the real visitor, so the traffic blends in as an ordinary customer. That is the whole appeal, and the whole problem.

Residential proxies split into a few forms. Rotating proxies swap the exit IP on a timer or on every request, cycling through a large pool of home addresses. Static residential, sometimes sold as ISP proxies, keep one home IP for a longer stretch when an operation needs a consistent identity. They sit at one end of a spectrum: a datacenter proxy uses an obvious hosting address, a mobile proxy uses a carrier IP shared by many subscribers, and a residential proxy uses the hardest-to-question address of all, a real home. A VPN, by comparison, routes everyone through a shared set of provider IP ranges that are far easier to recognize, which is part of why residential proxies have become a preferred choice when an actor wants to stay invisible. Residential proxies are, in short, the hardest class of anonymous proxy to detect.

Where residential proxy IPs come from

A residential proxy is only worth anything because its address belongs to a real household, so the networks selling them need a constant supply of real home connections to route through. In these networks, the exit node is rarely a server in a rack; it is someone's phone, laptop, or smart TV, enrolled through an app they installed for something else. That supply gets built in a few ways, most of them without the owner paying attention:

Bundled SDKs in ordinary apps. A normal-looking app, a game, a messenger, a screensaver, a "free" VPN, ships an embedded component that turns the device into an exit node in the background. Consent is usually buried in a privacy policy, and some of these run whether or not the screen is even on.
Bandwidth-sharing schemes. Apps that openly pay people a few dollars to share unused bandwidth, which in practice rents out the home connection as an exit node for whoever buys the pool.
Compromised consumer hardware. Routers, IP cameras, and smart TVs left on default passwords or outdated firmware get quietly enrolled into a relay network, the owner noticing nothing beyond an occasional slowdown.

Two consequences follow. First, the address carries genuine residential reputation, because it is a genuine residence, which is exactly why blocking one is risky and why the household behind it has no idea it is being used. Second, the pools are cheap, rented, and resold, so the set of addresses you flagged last week is a different set this week. A measurement study characterizing residential proxies, published on arXiv, describes exactly this churn, and it is why a static list never keeps up. Bitsight research in 2026 mapped more than 53 million unique residential-proxy exit IPs, with many overlapping known malware infections, a reminder of how much of this supply comes from compromised consumer devices.

Why residential proxies are so hard to detect

The methods that catch a datacenter proxy all lean on the address, and the address is the one thing a residential proxy gets right. A hosting range announces itself: its autonomous system number belongs to a cloud provider, its IP reputation is often already poor, and a blocklist can catch it. A residential exit defeats all three at once. The address belongs to a consumer ISP, so the ASN looks ordinary. It is a real home connection with no abuse history of its own, so its reputation is clean. And it rotates, so any list you build is stale before you finish it, and the old assumption that one IP means one person breaks completely.

This is why a consumer-looking IP is not, by itself, a reason to trust a session, and why residential proxy detection cannot live on the network address. The address has stopped being evidence. Everything around it has to do the work instead.

How residential proxy detection actually works

Since the IP is honest, detection reads the behavior, the device, and the connection around it, and looks for the places where a routed session cannot keep its story straight. Four kinds of signal carry the load.

Rotation and velocity. A real home connection does not jump from one city or ISP to another between requests in the same session. A rotating residential proxy does exactly that, so an address that moves faster than a person physically could, or that changes networks mid-session, is a strong tell. This is the same logic behind impossible travel, read at the level of a single session.

Connection density. One home gateway serves one household. When many unrelated accounts or a burst of automated actions all originate from the same residential address at the same time, the address is no longer behaving like a home, it is behaving like an exit node.

Device linkage. This is the one that matters most. The IPs scatter across a rotating pool, but the device behind them does not change. Reading the device rather than the address links the sessions the rotation was meant to separate, so a hundred fresh home IPs collapse back into the one machine driving them. When we tested traffic routed through rotating residential pools, this was the signal that held: the exit IP changed on nearly every request, but the device signature underneath stayed the same. The address rotates; the device does not.

Network contradictions. The transport layer often disagrees with the residential story. A TLS or JA4 fingerprint that matches a scripting library or a server stack, not a consumer browser, contradicts the home IP. Latency and round-trip timing can reveal the extra hop through an intermediary. And a WebRTC or DNS leak can expose the real datacenter address sitting behind the residential exit.

The principle tying these together is simple: a residential proxy can fake the address but not everything attached to it. The contradiction between the clean home IP and the device, behavior, and connection around it is the signal.

Residential vs datacenter proxy detection

The two are not the same job, because the address is informative in one case and useless in the other:

	Datacenter proxy	Residential proxy
Address type	Hosting or cloud range	Real consumer ISP home IP
IP reputation	Often already flagged	Clean, belongs to a real home
ASN / ownership	Cloud provider, easy to spot	Ordinary residential ISP
Blocklists	Reasonably effective	Stale almost immediately
What actually catches it	The address itself	The device, behavior, and connection around the address

Datacenter proxy detection can lean on the network layer. Residential proxy detection has to corroborate everything else, which is why it is the harder problem and why an IP lookup alone never settles it.

What residential proxy detection can and cannot do

Residential proxies are the hardest masked traffic to identify, and honest detection says so. No single signal is reliable: a clean home IP proves nothing, a rotation can be coincidence, a device match can be a shared family computer, and a busy home IP is not always one household, because carrier-grade NAT and large shared ranges can legitimately put many real users behind a single residential address. That is exactly why connection density has to raise the score rather than settle anything on its own. What works is corroboration, several weak-on-their-own signals pointing the same way, which is why good detection raises confidence toward, but never to, certainty. 99.9 percent is an honest ceiling; 100 percent is a sales claim.

It also helps to remember that residential proxies have legitimate uses, such as ad verification and price-comparison research, so their presence is a risk signal tied to what the session is trying to do, not proof of fraud on its own. A residential proxy on an idle page view is noise. The same proxy on a tenth signup from one device this week, with a datacenter TLS stack underneath, is a story worth acting on.

Detecting residential proxies with ShieldLabs

ShieldLabs uses device intelligence together with connection analysis and pre-built blocklists, and flags the connection with an anonymous-proxy signal. But because residential proxies can be used for legitimate reasons, that signal has to be weighed together with the other risk signals, such as anti-detect browser usage, OS mismatch, timezone mismatch, and others. This layered approach helps your team move from spotting anomalies to confident, well-grounded decisions.

The ShieldLabs analytics dashboard also surfaces the anomalies where many accounts trace back to one device or one account spreads across many devices, and assigns a risk score to each identified visitor. You get the risk score and named risk signals through the API and webhooks to make accurate, well-grounded decisions.

Sources

Stanford Secure Computer Systems Group: Residential Proxy Detection (RESIP research)
arXiv: Characterizing and Detecting Residential Proxies (2412.03023)
Wikipedia: Proxy server
Wikipedia: Autonomous system (Internet)
MDN Web Docs: WebRTC API
IETF: RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space (carrier-grade NAT)
Bitsight: Residential proxy services and malware ecosystems

FAQ

Can residential proxies be detected?

Yes, but not by the IP address alone. Because a residential proxy uses a real home IP with a clean reputation, reputation lists, ASN checks, and blocklists mostly miss it. Detection instead reads the signals around the address: rapid IP rotation across locations, many accounts behind one home gateway, the device that stays the same while the IPs change, and network contradictions like a datacenter-style TLS stack or a leaked real IP. Residential proxies are harder to detect than datacenter proxies or VPNs, but they are not undetectable.

What is the difference between a residential proxy and a datacenter proxy?

A datacenter proxy routes traffic through a hosting or cloud IP address, which is easy to recognize because the address belongs to a known provider and often already carries a poor reputation. A residential proxy routes through a real home IP assigned by a consumer ISP, so it looks like an ordinary visitor and defeats address-based checks. The practical result is that datacenter proxies are caught by the address itself, while residential proxies have to be caught by the device, behavior, and connection around the address.

Why do fraudsters use residential proxies?

Because a residential IP carries the trust of a real home connection. It lets one actor look like many separate, legitimate customers, sidesteps reputation and blocklist checks, places the traffic in a plausible location, and rotates to break rate limits and the one-IP-per-account assumption. That combination is why residential proxies show up behind multi-accounting, account takeover, and offer abuse.

Are residential proxies illegal?

The proxies themselves are not illegal, and they have legitimate uses such as ad verification and market research. What can be illegal is the activity routed through them, such as fraud or unauthorized access, and the way some networks source their IPs, by enrolling people's devices without clear consent, raises its own problems. For a detection layer, a residential proxy is a risk signal tied to what the session is doing, not an offense in itself.

Does ShieldLabs detect residential proxies?

ShieldLabs reads the device and connection behind a session rather than trusting the IP, so it links rotating residential IPs back to one device and weighs network contradictions like a mismatched TLS stack against the clean home address. Those signals feed a risk score from 0 to 100 with the reasons named. ShieldLabs scores the session and hands the result, through its API and webhooks, to the rules you build on top, and the free tier covers your first 5,000 identifications.

Originally published on the ShieldLabs blog.