Cross-Origin Headers für AWS CloudFront
CORP, COEP und COOP per Response Headers Policy konfigurieren — Cross-Origin Isolation gegen Spectre-Angriffe und Seitenkanalangriffe.
Cross-Origin Headers auf AWS CloudFront
Cross-Origin Headers (COOP, COEP, CORP) schützen gegen Spectre-basierte Seitenkanalangriffe und Cross-Origin-Informationslecks. Sie aktivieren die Cross-Origin Isolation im Browser, die Zugriff auf SharedArrayBuffer und hochauflösende Timer ermöglicht — und gleichzeitig verhindert, dass andere Tabs auf den Speicher Ihrer Anwendung zugreifen können. Cross-Origin Headers sind mit 30 von 166 Punkten ein gewichtiger Faktor im Wolf-Agents Web Security Check.
CloudFront bietet keinen dedizierten Block für Cross-Origin Headers in der Security Headers Config. Sie müssen alle drei Header als Custom Headers in der custom_headers_config setzen. Die AWS-Managed SecurityHeadersPolicy enthält keine Cross-Origin Headers — eine Custom Policy ist zwingend erforderlich.
Wichtig: Cross-Origin Isolation kann Drittanbieter-Embeds (YouTube, Google Maps, Payment-Widgets) blockieren. Testen Sie gründlich in einer Staging-Umgebung, bevor Sie die Header produktiv setzen. Nutzen Sie credentialless als Kompromiss zwischen Sicherheit und Kompatibilität.
Cross-Origin Headers per Terraform setzen
Setzen Sie alle drei Header als Custom Headers in der Response Headers Policy. COOP: same-origin isoliert den Browsing-Context, COEP: require-corp erzwingt CORP für alle Embeds und CORP: same-origin verhindert Cross-Origin-Einbettung Ihrer Ressourcen. Mit override = true stellen Sie sicher, dass Origin-Header überschrieben werden.
# terraform/cross-origin-headers.tf
resource "aws_cloudfront_response_headers_policy" "cross_origin" {
name = "cross-origin-headers-policy"
custom_headers_config {
# Cross-Origin-Opener-Policy
items {
header = "Cross-Origin-Opener-Policy"
value = "same-origin"
override = true
}
# Cross-Origin-Embedder-Policy
items {
header = "Cross-Origin-Embedder-Policy"
value = "require-corp"
override = true
}
# Cross-Origin-Resource-Policy
items {
header = "Cross-Origin-Resource-Policy"
value = "same-origin"
override = true
}
}
}
# Distribution mit Cross-Origin Policy
resource "aws_cloudfront_distribution" "main" {
default_cache_behavior {
response_headers_policy_id = aws_cloudfront_response_headers_policy.cross_origin.id
}
}CloudFront Function für routenspezifische Policies
Wenn bestimmte Routen (z.B. Blog mit YouTube-Embeds) weniger restriktive Cross-Origin Headers benötigen, nutzen Sie eine CloudFront Function. Die Function setzt je nach URI-Pfad unterschiedliche COEP- und COOP-Werte — strikte Isolation für die Anwendung, credentialless für Seiten mit Drittanbieter-Inhalten.
// CloudFront Function — routenspezifische Cross-Origin Headers
// Event: Viewer Response
function handler(event) {
var response = event.response;
var request = event.request;
var headers = response.headers;
// Basis-Header für alle Routen
headers['cross-origin-resource-policy'] = {
value: 'same-origin'
};
// Seiten mit Drittanbieter-Embeds: credentialless
if (request.uri.startsWith('/blog')
|| request.uri.startsWith('/media')) {
headers['cross-origin-opener-policy'] = {
value: 'same-origin-allow-popups'
};
headers['cross-origin-embedder-policy'] = {
value: 'credentialless'
};
} else {
// Alle anderen Routen: strikte Isolation
headers['cross-origin-opener-policy'] = {
value: 'same-origin'
};
headers['cross-origin-embedder-policy'] = {
value: 'require-corp'
};
}
return response;
}credentialless als kompatible Alternative
Wenn Sie Drittanbieter-Embeds (YouTube, Google Maps, iframes) einbetten, kann require-corp diese blockieren, weil die Drittanbieter keinen CORP-Header setzen. Die Alternative credentialless erlaubt Cross-Origin-Embeds, sendet aber keine Cookies oder Authentifizierung an die eingebetteten Ressourcen.
# Alternative: credentialless statt require-corp
# Weniger restriktiv — erlaubt Cross-Origin-Embeds ohne CORP
items {
header = "Cross-Origin-Embedder-Policy"
value = "credentialless"
override = true
}
# credentialless sendet keine Cookies/Auth bei Cross-Origin
# Vorteil: Drittanbieter-Embeds (YouTube, Maps) funktionieren
# Nachteil: Weniger sicher als require-corpVerifizierung
Prüfen Sie alle drei Header per curl. In den Browser DevTools können Sie die Cross-Origin Isolation mit crossOriginIsolated in der Console validieren — der Wert muss true sein, damit SharedArrayBuffer und hochauflösende Timer verfügbar sind. Vergessen Sie nicht, den CloudFront-Cache nach Policy-Änderungen zu invalidieren.
# Cross-Origin Headers prüfen
curl -sI https://ihre-domain.de | grep -i cross-origin
# Erwartete Ausgabe:
cross-origin-opener-policy: same-origin
cross-origin-embedder-policy: require-corp
cross-origin-resource-policy: same-origin
# Cross-Origin Isolation in Browser DevTools prüfen:
# Console: crossOriginIsolated === true
# Nach Policy-Änderung: Cache invalidieren
aws cloudfront create-invalidation \
--distribution-id E1234EXAMPLE \
--paths "/*"Häufige Fehler
COEP blockiert Drittanbieter-Embeds
require-corp blockiert alle Cross-Origin-Ressourcen ohne CORP-Header. YouTube-Embeds, Google Fonts und CDN-Scripts werden blockiert. Nutzen Sie credentialless oder fügen Sie crossorigin-Attribute hinzu.
COOP bricht window.opener
same-origin isoliert den Browsing-Context — window.opener wird null. OAuth-Popups und Payment-Fenster funktionieren nicht mehr. Nutzen Sie same-origin-allow-popups als Alternative für Seiten mit Popup-Flows.
Nur COEP ohne COOP gesetzt
Cross-Origin Isolation erfordert beide Header: COOP und COEP. Nur COEP allein aktiviert nicht crossOriginIsolated = true im Browser. Setzen Sie immer beide gemeinsam für volle Isolation.
Cache-Invalidierung nach Policy-Änderung vergessen
Nach einer Änderung an der Response Headers Policy liefert CloudFront gecachte Responses ohne die neuen Header aus. Erstellen Sie eine Invalidierung: aws cloudfront create-invalidation --paths "/*".
Compliance-Relevanz
PCI DSS 4.0 fordert Schutz gegen bekannte Browser-Schwachstellen — Cross-Origin Isolation adressiert Spectre-basierte Seitenkanalangriffe, die sensible Daten aus dem Browser-Speicher lesen können. OWASP empfiehlt Cross-Origin Headers als Defense-in-Depth-Maßnahme gegen clientseitige Angriffe. NIS2 fordert technische Maßnahmen zum Schutz der Vertraulichkeit von Daten. BSI IT-Grundschutz empfiehlt die Härtung von Webanwendungen durch Security Header. Der Wolf-Agents Web Security Check prüft alle drei Cross-Origin Header auf korrekte Konfiguration und Konsistenz.
Wie steht Ihre Domain bei Cross-Origin Headers?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.