Chrome 150 updates how Dedicated and Shared Workers handle [data: URLs](https://datatracker.ietf.org/doc/html/rfc2397). Rather than automatically inheriting the security origin of the script or page that created them, these workers will now be assigned a unique opaque origin. This alignment with the worker [HTML specification](https://www.w3.org/TR/2021/NOTE-workers-20210128/#worker) enhances security by isolating these workers from the creator's same-origin state, preventing them from accessing sensitive data via mechanisms like `BroadcastChannel` or same-origin storage. To maintain correct isolation boundaries, these workers still reside within the same storage partition (for example, by preserving the top-level site or nonce) as their creator. This security adjustment is enabled by default across desktop and mobile platforms. Administrators can review or verify security boundaries using their centralized configurations. For technical implementation details and specification references, see Step 3 of the [HTML Living Standard Worker Settings](https://html.spec.whatwg.org/multipage/workers.html#script-settings-for-workers).
Currently, Dedicated and Shared Workers created from data: URLs in Chrome inherit the security origin of their creator, which deviates from the HTML specification. This behavior allows these workers to access sensitive same-origin resources, such as BroadcastChannel, LocalStorage, and IndexedDB, potentially leading to data leakage where untrusted or dynamically generated scripts can join a page's same-origin communication state. This change aligns Chrome with the standard by assigning a unique opaque origin to such workers, ensuring proper security isolation. It also improves interoperability, as other major browser engines already follow the specification by not inheriting the origin for data: URL workers. The implementation maintains necessary isolation boundaries by preserving the creator's storage partition (e.g., top-level site or nonce).