Tracking inside web workers: the consent gap your wrapper can't see
October 1, 2026 · CookieBastion
A web worker is a separate JavaScript thread, and most consent wrappers only watch the main thread. Tracking code running inside a worker can fire network requests that never pass through the consent checks your wrapper installed, which means your banner can say no while a worker says yes. The fix is to gate worker creation on consent state and pass consent updates into workers explicitly, then verify with network-level testing that worker traffic actually stops on reject.
What web workers change about tracking
Workers were built for heavy computation off the main thread: image processing, data crunching, background sync. Trackers adopted them for the same reasons, plus one more: code running in a worker is harder to observe. It does not show up in the usual script inventories, it survives some naive blocking approaches, and it keeps running when the main thread is idle.
The tracking use cases are practical. Fingerprinting libraries run their canvas and audio probes in workers to avoid jank. Analytics SDKs batch and compress events in workers before sending. Session replay tools offload their recording. None of this is exotic anymore; it is standard practice in the tracking libraries your site probably loads.
Why the consent wrapper misses it
Most consent wrappers work by controlling the main thread: they hold back script tags, wrap known globals, and intercept the network calls they can see. A worker is a separate global scope. The wrapper's patches to fetch or XMLHttpRequest on the main thread do not apply inside the worker, and a worker created before consent is granted keeps its own copy of whatever the page gave it at creation time.
The timing makes it worse. Workers are often created at page load, before the visitor has made any choice, because the tracking library wants its pipeline ready. If the library then buffers events and sends them later, the network request can fire after consent was granted or rejected, from a context that never checked.
Detecting worker traffic
You cannot find this with a script inventory alone. Test at the network level: load the page, reject all consent, and watch for requests that still fire, then trace their initiators. In Chromium devtools, worker-initiated requests show the worker as the initiator, which is the tell. Filter the network log by the tracking domains you know and look for anything with a worker in the initiator chain.
Also check what spawns the workers. Search the bundled JavaScript for Worker constructor calls and for the tracking library names you recognize. A worker spawned by an analytics SDK at import time is the classic shape of this problem: the consent wrapper never got a chance to intervene because the worker existed before the wrapper ran.
The fix: gating workers on consent
The robust pattern has two parts. First, do not let tracking libraries create workers until the relevant consent is granted. This usually means deferring the library's initialization behind your consent state, not just its network calls. If the library offers a manual initialization mode, use it; if it self-initializes on import, load it dynamically after consent.
Second, pass consent state into workers explicitly with postMessage. Workers that need to keep running, for genuinely necessary functionality, should receive consent updates as messages and gate their own network calls on the latest state they received. A worker holding a stale granted state after the visitor withdrew consent is the same bug in a different shape.
Testing it
Add worker traffic to your consent test routine. The test is simple: reject everything, then assert that no requests to tracking domains originate from workers. Automate it if you can, because this is exactly the kind of regression that reappears when someone upgrades the analytics SDK and the new version moves more work into a worker. The banner did not change; the architecture underneath it did.