Skip to content
All fingerprint checksNative function integrity

Element.attachShadow untampered (shape + closed/open behaviour)

Check id shadow-dom-integrity

What an ordinary browser yields

attachShadow is name "attachShadow", length 1, native source in both realms; a closed root returns null from element.shadowRoot and an open root returns itself.

What a detector infers

The check reads Element.prototype.attachShadow four ways and asserts they agree: its name is "attachShadow", its length (declared parameter count) is 1, it stringifies as native code — measured both in this realm and through a fresh iframe's Function.prototype.toString — and its runtime behaviour is correct, meaning a shadow root created with {mode:"closed"} is not exposed through element.shadowRoot while a {mode:"open"} one is. These come from different layers: name, length and source are properties of the function object, while the closed/open visibility is enforced by the DOM implementation itself. A detector that finds them disagreeing learns the function was replaced with a JavaScript wrapper. This surface matters because the newest Kasada scripts added eleven probes that do exactly this — attachShadow.name, .toString(), .length and shadowRoot.closed/open, in both the window and an iframe — since some anti-detect builds wrap attachShadow to stop pages from fingerprinting through closed roots, and the wrapper's own name/length/source or its handling of the closed/open contract gives it away. The cross-realm read is what defeats a wrapper that hides its own toString: the iframe's untouched toString stringifies the main-realm function without asking the wrapper.

How to resolve it

Leave Element.prototype.attachShadow native. If a build wraps it to control shadow-DOM fingerprinting, that wrapper is visible through its name, length, source or its closed/open behaviour — do the spoofing at the engine level instead, where the function object and the DOM contract stay coherent.

Why does toString reveal a hooked function?

Read in the wild by

Kasada

Its newest probe family — 11 probes covering attachShadow's identity and closed/open root behaviour, in both realms.

window_attach_shadow_name / _tostring / _length, window_shadow_root_closed / _open + the iframe_* twins

Kasada ips.js teardown — the full 427-probe list

Every attribution traces to a published artifact. See the sources and their limits.

Nearby checks in Native function integrity

See all 13 checks in Native function integrity
Who builds this test

Clearcote is a browser built for fingerprint coherence

It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.

This audit takes no position on how Clearcote scores on Native function integrity checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.

See the other checks in Native function integrity — the family shadow-dom-integrity belongs to.