HTTP CSP worker-src

Die worker-src Direktive der Content Security Policy kontrolliert die Quellen von Worker SharedWorker und ServiceWorker Scripts.

Typ

CSP-Direktive zur Kontrolle von Worker-Script-Quellen für sichere Background-Thread-Execution in Progressive Web Apps und API-getriebenen SPAs durch granulare Worker-Script-Whitelisting.

Syntax

Die Direktive definiert erlaubte Quellen für Worker-Scripts. Bei Fehlen fällt sie auf child-src, dann script-src, dann default-src zurück.

http 
Content-Security-Policy: worker-src <source-list>

Direktiven

Die worker-src Direktive kontrolliert Worker-Script-Quellen durch URL-Whitelisting für sichere Background-Thread-Execution.

source-list
Erlaubte Quellen für Worker-Scripts. Unterstützt URLs, 'self', 'none', aber nicht 'unsafe-inline' (Worker-Scripts sind immer externe Dateien). Kontrolliert new Worker(), new SharedWorker() und navigator.serviceWorker.register().
'none'
Blockiert alle Worker-Typen vollständig. Verhindert Service Worker SharedWorker und Web Worker Registrierung für Security-kritische Banking-APIs.

Beispiele

Praktische Szenarien für worker-src in Progressive Web Apps API-Dashboards und Microservice-Frontends mit Service Worker Offline-Caching.

PWA mit Service Worker für API-Caching

Progressive Web Apps nutzen Service Worker für Offline-Funktionalität mit API-Response-Caching:

http 
HTTP/2 200 OK
Content-Type: text/html
Content-Security-Policy: worker-src 'self'; script-src 'self' https://cdn.example.com

<!DOCTYPE html>
<html>
<head>
  <script src="https://cdn.example.com/app.js"></script> <!-- OK durch script-src -->
</head>
<body>
  <script>
    // Erlaubt (same-origin Service Worker)
    navigator.serviceWorker.register('/sw.js').then(reg => {
      console.log('Service Worker registered');
    });

    // Erlaubt (same-origin Web Worker)
    const worker = new Worker('/api-worker.js');

    // Blockiert (external Worker nicht erlaubt)
    const externalWorker = new Worker('https://cdn.example.com/worker.js');
  </script>
</body>
</html>

Worker-Scripts müssen same-origin sein. CDN-Scripts sind nur für Main-Thread erlaubt.

API-Dashboard mit Multi-Worker-Architecture

Datenintensive Dashboards nutzen mehrere Worker-Typen für API-Datenverarbeitung:

http 
HTTP/2 200 OK
Content-Type: text/html
Content-Security-Policy: worker-src 'self' https://workers.example.com; script-src 'self'

<!DOCTYPE html>
<html>
<script>
  // Web Worker für CPU-intensive API-Response-Transformation
  const dataWorker = new Worker('/workers/transform-data.js'); // OK ('self')
  dataWorker.postMessage({apiData: {...}});

  // Shared Worker für Cross-Tab-API-State-Synchronisation
  const syncWorker = new SharedWorker('https://workers.example.com/sync.js'); // OK (whitelisted)
  syncWorker.port.start();

  // Service Worker für API-Response-Caching
  navigator.serviceWorker.register('/workers/cache-strategy.js'); // OK ('self')

  // API-Aufruf mit Worker-basiertem Processing
  fetch('/api/large-dataset')
    .then(r => r.json())
    .then(data => dataWorker.postMessage({action: 'process', data}));
</script>
</html>

Verschiedene Worker-Typen von 'self' und dediziertem Worker-CDN sind erlaubt.

Microservice-Frontend mit deaktivierten Workers

Security-kritische Banking-APIs verbieten alle Worker-Execution:

http 
HTTP/2 200 OK
Content-Type: text/html
Content-Security-Policy: worker-src 'none'; script-src 'self'
X-Content-Type-Options: nosniff

<!DOCTYPE html>
<html>
<script>
  // Blockiert (alle Worker verboten)
  const worker = new Worker('/worker.js'); // TypeError

  // Blockiert
  navigator.serviceWorker.register('/sw.js'); // SecurityError

  // Main-Thread-Script OK
  const result = processData(apiResponse);
</script>
</html>

Alle Worker-Typen blockiert. Nur Main-Thread-Execution erlaubt.

Worker-Registration-Flow

Visualisierung der Service Worker Registrierung mit worker-src Policy-Enforcement und Offline-API-Caching-Integration.

plantuml 
@startuml
actor User
participant "Browser" as Browser
participant "Main Thread" as Main
participant "Service Worker" as SW
participant "API Server" as API
participant "CSP Engine" as CSP

User -> Browser: Load PWA
Browser -> API: GET /app
API -> Browser: HTML + CSP: worker-src 'self'; script-src 'self'

Main -> Main: Initialize application
Main -> CSP: navigator.serviceWorker.register('/sw.js')
CSP -> CSP: Validate worker source
CSP -> CSP: Check origin: same-origin ('self')
CSP -> Main: Allow Service Worker registration

Main -> API: GET /sw.js
API -> Main: Service Worker script
Main -> SW: Install and activate
SW -> SW: Setup API cache strategies
note right: Offline-Funktionalität aktiv

User -> Main: Trigger API call
Main -> SW: fetch('/api/data') intercepted
SW -> SW: Check cache
alt Cache hit
    SW -> Main: Return cached response
    note right: Instant response
else Cache miss
    SW -> API: GET /api/data
    API -> SW: API response
    SW -> SW: Cache response
    SW -> Main: Return response
end

Main -> CSP: new Worker('/api-worker.js')
CSP -> CSP: Validate: same-origin
CSP -> Main: Allow Worker creation
Main -> API: GET /api-worker.js
API -> Main: Worker script

Main -> Main: Create Worker instance
Main -> Main: worker.postMessage({data})
note right: Background processing

alt Blocked: External Worker
    Main -> CSP: new Worker('https://cdn.example.com/worker.js')
    CSP -> CSP: Check origin: external domain
    CSP -> CSP: Not in whitelist
    CSP -> Main: SecurityError
    note right: External Worker blockiert
end
@enduml

Vorteile für die Systemarchitektur

Worker-Quellen-Kontrolle sichert Service Worker Registrierung und Background-Thread-Execution für PWA-Security und API-Datenverarbeitung.

  • PWA-Security: Kontrolliert Service Worker Registrierung für Offline-Funktionalität verhindert malicious Service Worker die API-Responses manipulieren könnten
  • Background-Thread-Isolation: Sichert Web Worker und Shared Worker für CPU-intensive API-Datenverarbeitung ohne Main-Thread zu blockieren
  • Granulare Fallback-Chain: Fällt auf child-src script-src default-src zurück ermöglicht flexible Policy-Architekturen für verschiedene Worker-Typen

Spezifikation

Die worker-src Direktive ist Teil der CSP Level 3 Spezifikation:

Wichtig: Service Worker haben eigenen CSP-Kontext. Die worker-src Policy des Parent-Documents kontrolliert die Registrierung, aber der Service Worker selbst kann eigene CSP-Header via fetch Event setzen.

Weitere Spezifikationen

CSP child-src Directive, CSP connect-src Directive