How to Detect Website Fingerprint Scripts: A DIY Guide

On August 20, 2026, developer Matt Callaghan (blog laserphile) published an analysis of a strange bug: his multipoint Bluetooth headphones stopped switching from the computer to the phone every time an AliExpress tab was open. He didn't guess — he instrumented the browser APIs and looked at what was happening inside the page. It turned out that two obfuscated scripts from Alibaba's anti-fraud stack were raising the audio context and fingerprinting the device through inaudible sound.

This is a perfect illustration of what almost no one does before setting up profiles or launching a parser: not reading the site's detection stack, but guessing it. Below is a practical method to create a detection map of a specific site by yourself, in an hour, without reversing obfuscation and without paid services.

Why Create a Detection Map

A typical cycle looks like this: accounts get banned — we randomly tweak the anti-detect browser settings — change proxies — banned again. There is no data between "banned" and "settings": it is unclear what exactly the site is reading and at what layer it catches.

A detection map closes this gap. It is a list: which protection vendor is in place, which scripts implement it, which APIs they touch, and where the results go. It then becomes clear where the actual bottleneck is — in the IP, in the network fingerprint, or in the hardware layer of the browser. This is equally useful for three audiences:

• Multi-accounting — to understand which signal merges profiles. They have different IPs, but the audio stack, WebGL renderer, and hardwareConcurrency are often the same across the entire farm.
• Scraping — to determine whether it is worth launching a browser at all or if the task can be solved with an HTTP client with a correct TLS fingerprint.
• Privacy — to see what exactly the store or service collects about your device beyond cookies.

Step 1. Identify the Protection Vendor via Network

The first thing you do is open DevTools on the Network tab, load the page, and look at the headers and cookies of the first document. The identifying marks are known and stable:

• CF-RAY in response headers and cookie cf_clearance — Cloudflare.
• Cookie _abck and a script with the function bmak — Akamai Bot Manager.
• Variables and cookies prefixed with _px — PerimeterX (HUMAN).
• Cookie datadome and a separate JS from the vendor's domain — DataDome.
• An empty 429 without a response body — a characteristic signature of Kasada.

If you’re too lazy to do it manually, there are open detectors like microlinkhq/is-antibot (30+ providers) and browser extension detectors for 26+ vendors. They provide a quick first answer but do not address the main question — what exactly is being measured in your browser. You need to dig deeper for that.

Step 2. Extract a List of Suspicious Scripts

Filter the Network by JS type and write down everything that loads not from the main domain or is located in service directories. In the case of AliExpress, there were two files with clearly service paths:

• assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.js
• assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js

Signs of an anti-fraud script: obfuscated code, version in the path, a separate subdomain for static content, lack of any connection to the visual part of the page. There’s no need to open and read the obfuscation — in the next step, the script will reveal itself.

Step 3. Instrument the Fingerprint API

This is the core of the method and exactly what Callaghan did: he wrapped the AudioContext constructor and AudioNode.prototype.connect(), after which he saw two live audio contexts on a page that had no media elements and no calls to play().

The logic is simple: you replace the method you are interested in with your wrapper, which logs the call with the stack and passes control to the original. The call stack shows which script triggered the API. It is easiest to insert such a snippet through DevTools Sources → Snippets or through an extension that executes code on document-start — it’s important to do this before the anti-fraud script loads.

The minimum set of traps that covers most signals:

1. HTMLCanvasElement.prototype.toDataURL and getImageData — canvas fingerprint.
2. WebGLRenderingContext.prototype.getParameter — graphics card model and driver, shader precision.
3. AudioContext / OfflineAudioContext and AudioNode.prototype.connect — audio fingerprint.
4. Getters navigator.hardwareConcurrency, navigator.deviceMemory, navigator.plugins, navigator.webdriver.
5. RTCPeerConnection — WebRTC and local addresses.
6. screen.width/height, devicePixelRatio, Intl.DateTimeFormat().resolvedOptions() — screen and timezone.
7. navigator.mediaDevices.enumerateDevices — list of audio and video devices.

As a result of running this, you will have a list of which of these APIs were actually called, how many times, and by whom. In the analyzed case, Alibaba's scripts touched the canvas and toDataURL, the WebGL renderer and shader precision, audio through an oscillator and analyzer, screen sizes and devicePixelRatio, hardwareConcurrency and deviceMemory, plugins, codec support, WebRTC, performance timings, mouse movement patterns and touches, device motion sensors, and automation-indicator properties.

What the Audio Graph Did

It’s useful to understand what the measurement looks like to recognize it in other places. The graph was as follows: sawtooth oscillator → AnalyserNode → ScriptProcessorNode, reading the analysis result → GainNode with zero gain → destination. There is no sound, volume is irrelevant — it simply does not exist. But connecting to destination, as the author puts it, forces the browser to actively process the graph, even though the final volume is zero. It was this live audio path that kept the Bluetooth connection open, breaking the multipoint switching of the headphones.

Differences in processing this signal depend on the processor, sound hardware, OS, browser, and drivers — hence the stable identifier that survives IP changes and cookie clearing. A detailed analysis of this layer and profile settings for it can be found in the article about protection against Audio Context Fingerprinting.

Step 4. Capture the Result Submission

Collection without submission is pointless, so the next step is to find out where the collected fingerprint goes. Filter the Network by XHR/Fetch and separately look at requests like ping — these are generated by navigator.sendBeacon, which telemetry scripts love to use because it survives page navigation.

It is almost always useful to additionally wrap fetch, XMLHttpRequest.prototype.send, and navigator.sendBeacon — then you will see the request body before it goes out. Be prepared for the content to be serialized and encrypted: in the case of AliExpress, the data was encrypted before being sent to Alibaba's telemetry. But even so, you get two facts: the recipient's address and the moment of submission relative to your actions.

If the site operates not only in the browser but also through a mobile app or a separate client, the same question is solved at the traffic level rather than the DOM — the interception and analysis method is described in the analysis of traffic audit via mitmproxy.

Step 5. Compare the Map with Your Profile

Now you have a list of signals that the site actually reads. The next step is to check what your working profile returns for these signals. The order is as follows: you take values in a regular browser, then in each anti-detect profile, and compare.

Two things are important simultaneously: the values must differ between profiles and be stable within one profile across sessions. A profile whose fingerprint jumps with each launch looks just as suspicious to anti-fraud as ten profiles with identical fingerprints.

Check separately that the substitution exists at the necessary layer. Here, the variation across browsers is telling: Firefox from version 118 gives a constant WebAudio output, and according to the analysis, 99.24% of users reduce to three values; Brave mixes in random data and since August 22, 2026, blocks these specific AliExpress scripts, reminding that protection against audio fingerprinting has been enabled by default for over six years; Safari mixes errors into audio buffers; Chrome has no aggressive protections.

Pitfalls

• The script has already executed. Blocking the file does not kill the already created audio context — the author explicitly notes that open tabs should be closed. The same applies to your instrumentation: if the wrapper was applied after the script, you will not see anything.
• Blocking breaks functionality. The anti-fraud stack often also handles legitimate things — authorization, payment, anti-bot protection against real abuse. Creating a detection map and cutting out scripts are different tasks; the latter breaks the site.
• There is not just one version of detection. The stack may differ by geo, device type, and A/B group. It makes sense to create a map from the IP and device you are actually working from; otherwise, you are describing someone else's configuration.
• The instrumentation itself is detected. Overridden native methods lose their correct toString, and an attached debugger leaves traces. For reconnaissance, this is not critical, but do not confuse a reconnaissance profile with a combat one — automation masking techniques are discussed in the guide on masking headless browsers.

What Proxy is Needed for the Result

The main practical takeaway from such a map is almost always the same: IP is just the first layer, and it is checked before all others. If anti-fraud sees the hosting address at the request stage, the audio graph and canvas will simply not come into play — you will get a challenge or an empty output and will be fixing the wrong thing.

Therefore, the logic of selection is as follows. For sites with a serious stack (Akamai, DataDome, PerimeterX, proprietary developments at the level of Alibaba), the base is residential proxies — addresses of real providers that are not filtered out at the first hurdle. For mobile applications and sites where the main audience is on smartphones, mobile proxies are closer to the natural profile: the operator's CGNAT makes the address inherently shared among many real users.

And the reverse is also true: if the map showed that the site is limited by headers and cookies, and there is no heavy JS fingerprinting — a browser farm is excessive, and the task can be solved with a regular HTTP client and data center addresses.

Conclusion

The case with the headphones is valuable not for the fact of audio fingerprinting — that has been known for years. It is valuable for the method: the person did not rely on guesses but wrapped two methods of the browser API and, in one evening, obtained a complete list of what is being collected from him and the address to which it goes. The same technique takes an hour on any site you work with and replaces months of randomly tweaking settings. Create a detection map before fixing bans — otherwise, you risk spending your budget on proxies where the problem was an identical WebGL renderer across all profiles.