COOP, COEP und CORP

Die drei Header im Überblick

COOP und COEP werden auf die HTML-Seite gesetzt, CORP auf die eingebetteten Ressourcen (Bilder, Skripte, Iframes).

Wenn COOP=same-origin UND COEP=require-corp gesetzt sind, ist die Seite cross-origin isolated. Folgen:

• Eigener Browser-Prozess möglich (Spectre-Schutz).
• SharedArrayBuffer und performance.now() mit hoher Auflösung freigeschaltet.
• window.opener zu cross-origin-Fenstern ist null.

COOP — Cross-Origin-Opener-Policy

Problem: Wenn deine Seite ein Popup öffnet oder von einem fremden Tab via window.open() geöffnet wurde, haben beide Seiten via window.opener Zugriff aufeinander. Das hat in der Vergangenheit zu mehreren XS-Leak-Klassen geführt.

Werte:

• unsafe-none (Default) — alte Verhalten, Cross-Origin-Opener-Verbindung möglich.
• same-origin-allow-popups — diese Seite verliert Opener-Connection nur zu Cross-Origin-Popups; eigene Popups bleiben verbunden.
• same-origin — strikteste Variante; Opener-Connection zu Cross-Origin-Seiten ist gekappt.

Beispiel:

Cross-Origin-Opener-Policy: same-origin

Wirkung: Cross-Origin-Tab, der via window.open() deine Seite geöffnet hat, kann nicht mehr auf window.opener zugreifen. Dieselbe Seite mit anderer Origin im Iframe — kein Zugriff.

Use-Case auch ohne Cross-Origin-Isolation: COOP alleine ist ein wertvoller Schutz gegen Tab-napping und window.opener-Manipulation. Auch ohne COEP empfehlenswert.

COEP — Cross-Origin-Embedder-Policy

Problem: Eingebettete Ressourcen (Bilder von fremden Domains, iframes mit Third-Party-Content) können in Spectre-Klassen ausgenutzt werden, um Cross-Origin-Daten zu leaken.

Werte:

• unsafe-none (Default) — eingebettete Cross-Origin-Ressourcen sind okay ohne explizite Erlaubnis.
• require-corp — Cross-Origin-Ressourcen MÜSSEN entweder mit CORP-Header zustimmen oder mit CORS-Header (für korrekt CORS-fetched).
• credentialless — Cross-Origin-Requests gehen ohne Credentials raus (keine Cookies). Schwächere Variante, dafür weniger Migration nötig.

Wirkung von require-corp: wenn eine Cross-Origin-Resource keinen passenden CORP-Header sendet, blockt der Browser das Laden. Bilder, Skripte, Iframes von fremden Domains brechen — außer sie spielen mit.

Cross-Origin-Embedder-Policy: require-corp

credentialless als pragmatische Alternative:

Cross-Origin-Embedder-Policy: credentialless

Bei credentialless sendet der Browser Requests zu Cross-Origin-Ressourcen ohne Cookies/Credentials — dadurch ist Spectre-Leak von User-spezifischen Daten unmöglich, weil die Ressourcen Public-Versionen sind. Erfordert keine Server-Änderungen bei den Drittparteien. Weniger restriktiv, aber leichter zu deployen.

CORP — Cross-Origin-Resource-Policy

Problem: Eine Resource, die du auslieferst (Bild, JS-File, JSON), kann von beliebigen anderen Origins eingebunden werden — was historisch nicht problematisch war, mit Spectre aber zur Daten-Leak-Quelle wurde.

Werte:

• same-origin — nur eigene Origin darf diese Ressource laden.
• same-site — nur eigene Site darf laden (eigene Origin plus Subdomains). „Site" = registrierbares Schema-Domain-Paar.
• cross-origin — beliebig (für absichtlich öffentliche Resources).

Beispiel — Avatare nur für eigene App:

# /avatars/123.jpg
Cross-Origin-Resource-Policy: same-origin
# → nur eigene Origin darf das Bild laden

Beispiel — Public-API mit CORS:

Access-Control-Allow-Origin: *
Cross-Origin-Resource-Policy: cross-origin
# → bewusst öffentlich erlaubt

Default-Empfehlung: für eigene Resources Cross-Origin-Resource-Policy: same-origin (oder same-site bei Multi-Subdomain-App) — verhindert, dass fremde Sites deine Resources einbetten und für XS-Leak-Klassen nutzen.

Cross-Origin Isolation aktivieren

Mit beiden Headern setzt der Browser die Seite in „cross-origin isolated" mode:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Prüfung im JS:

if (self.crossOriginIsolated) {
  console.log('Cross-Origin Isolation aktiv');
  // SharedArrayBuffer, performance.measureUserAgentSpecificMemory(), etc.
}

Was freigeschaltet wird:

• SharedArrayBuffer — High-Performance-Worker-Kommunikation. Für WebAssembly-Apps und manche Game-Engines essentiell.
• performance.now() mit hoher Auflösung (Mikrosekunden statt Millisekunden).
• performance.measureUserAgentSpecificMemory() — Memory-Profiling.
• Atomics.wait() und verwandte APIs.

Was Bedingung ist:

• Alle Cross-Origin-Subresources (Bilder, Skripte, Fonts, iframes) müssen mit CORP oder CORS antworten.
• Bestehende Apps haben dabei oft broken Drittparteien — Migrations-Aufwand.

Migrations-Pfad

Phase 1 — COOP allein:

Cross-Origin-Opener-Policy: same-origin ohne COEP. Wertvoller Schutz, kostenlos. Macht keine Drittpartei-Ressourcen kaputt. Mindeststandard für moderne Apps.

Phase 2 — CORP auf eigene Resources:

Pro Resource den korrekten CORP-Header setzen — same-origin für privat, cross-origin für absichtlich öffentliche. Bereitet Phase 3 vor.

Phase 3 — COEP mit Report-Only:

Cross-Origin-Embedder-Policy-Report-Only: require-corp testet, welche Drittpartei-Resources scheitern würden. Reporting-Endpoint sammelt die Violations.

Phase 4 — COEP enforce:

Wenn alle Drittparteien geklärt sind (CORS-fetched oder mit korrektem CORP), Header von Report-Only auf Enforce wechseln. Damit ist Cross-Origin Isolation aktiv.

Realistische Timeline: für eine App mit vielen Embeds (Werbung, Social Widgets, Maps, Videos) Monate. Für eine SPA mit eigenem Backend deutlich schneller.

credentialless als Workaround: Wenn Drittparteien keine CORP-Header setzen und nicht kontrollierbar sind, ist Cross-Origin-Embedder-Policy: credentialless der einfachere Migration-Pfad. Funktional fast gleich, Migration deutlich weniger schmerzhaft.

Reporting für COOP/COEP

Beide Header unterstützen Reporting-API:

Reporting-Endpoints: isolation-endpoint="https://csp-report.example.com/isolation"
Cross-Origin-Opener-Policy: same-origin; report-to=isolation-endpoint
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to=isolation-endpoint

Reports kommen für:

• COOP-Violations — fremde Origin versucht via window.opener zuzugreifen.
• COEP-Violations — Cross-Origin-Resource ohne CORP/CORS würde geblockt.

Die Reports zeigen pro Page genau, welche Embeds problematisch sind — Migration wird zielgerichtet.

Praktische Konfiguration

nginx:

# Für HTML-Pages
location / {
    add_header Cross-Origin-Opener-Policy "same-origin" always;
    add_header Cross-Origin-Embedder-Policy "require-corp" always;
    # ...
}

# Für eigene Static-Resources
location /static/ {
    add_header Cross-Origin-Resource-Policy "same-origin" always;
    # ...
}

# Für Public-API
location /api/public/ {
    add_header Access-Control-Allow-Origin "*";
    add_header Cross-Origin-Resource-Policy "cross-origin" always;
    # ...
}

Express:

import helmet from 'helmet';

app.use(helmet({
  crossOriginOpenerPolicy: { policy: 'same-origin' },
  crossOriginEmbedderPolicy: { policy: 'require-corp' },
  crossOriginResourcePolicy: { policy: 'same-origin' },
}));

// Pro Public-Endpoint überschreiben
app.get('/api/public/data', (req, res) => {
  res.setHeader('Cross-Origin-Resource-Policy', 'cross-origin');
  // ...
});

Weiterführende Ressourcen

Externe Quellen

• web.dev — Making your website cross-origin isolated
• web.dev — Cross-Origin Isolation Guide
• MDN — COOP
• MDN — COEP
• MDN — CORP
• HTML Spec — COEP
• Chrome — COEP credentialless

Verwandte Artikel

• Secure-Headers-Übersicht
• CSP-Deployment
• CORS
• Sandbox und Prozess-Isolation (Kap 4 — Browser-Sicht)
• HSTS und HTTPS-Only