CSP für AWS CloudFront konfigurieren
Content Security Policy auf CloudFront einrichten: Statische CSP per Response Headers Policy, dynamische Nonces per CloudFront Function — von Report-Only bis Enforcement.
Content Security Policy auf AWS CloudFront
Content Security Policy (CSP) ist der wichtigste HTTP-Security-Header gegen Cross-Site Scripting (XSS). Er teilt dem Browser mit, welche Ressourcen geladen werden dürfen — und blockiert alles andere. CSP ist mit 35 von 166 Punkten der einflussreichste Header im Wolf-Agents Web Security Check.
AWS CloudFront bietet zwei Wege für CSP: Eine statische CSP über die Response Headers Policy für einfache Setups ohne Nonces. Oder eine dynamische CSP mit Nonces über CloudFront Functions im Viewer-Response Event. Die Function generiert pro Request einen zufälligen Nonce und fügt ihn in den CSP-Header ein.
Wichtig: Die AWS-Managed SecurityHeadersPolicy enthält keine CSP. Sie müssen CSP immer manuell konfigurieren — entweder als Custom Header in der Policy oder per CloudFront Function.
Statische CSP per Terraform (Report-Only)
Beginnen Sie immer im Report-Only-Modus. Der Browser meldet CSP-Verstöße in der Konsole und an Ihren Reporting-Endpoint, blockiert aber keine Ressourcen. Für einfache Setups ohne Nonces genügt ein Custom Header in der Response Headers Policy.
# terraform/csp-report-only.tf — Statische CSP
resource "aws_cloudfront_response_headers_policy" "csp_policy" {
name = "csp-report-only-policy"
custom_headers_config {
items {
header = "Content-Security-Policy-Report-Only"
value = "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'; report-uri /api/csp-report"
override = true
}
}
}Eine statische CSP ohne Nonces erfordert 'unsafe-inline' für Inline-Scripts, was den XSS-Schutz reduziert. Für maximale Sicherheit nutzen Sie CloudFront Functions mit dynamischen Nonces (Schritt 2).
CloudFront Function für dynamische Nonces
Für maximale Sicherheit generieren Sie pro Request einen zufälligen Nonce. CloudFront Functions laufen auf allen Edge Locations, kosten ein Sechstel von Lambda@Edge und haben ein 10-KB-Code-Limit — für CSP-Nonces mehr als ausreichend.
// CloudFront Function — CSP mit dynamischem Nonce
// Event: Viewer Response
function handler(event) {
var response = event.response;
var headers = response.headers;
// Zufälligen Nonce generieren (24 Zeichen)
var nonce = crypto.randomUUID().replace(/-/g, '').substring(0, 24);
// CSP mit Nonce + strict-dynamic
headers['content-security-policy'] = {
value: "default-src 'self'; "
+ "script-src 'self' 'nonce-" + nonce + "' 'strict-dynamic'; "
+ "style-src 'self' 'unsafe-inline'; "
+ "img-src 'self' data: https:; "
+ "font-src 'self'; "
+ "connect-src 'self'; "
+ "object-src 'none'; "
+ "base-uri 'self'; "
+ "form-action 'self'; "
+ "frame-ancestors 'self'"
};
return response;
}# terraform/cloudfront-function-csp.tf
resource "aws_cloudfront_function" "csp_nonce" {
name = "csp-nonce-injection"
runtime = "cloudfront-js-2.0"
comment = "CSP mit dynamischem Nonce"
publish = true
code = file("cloudfront-function.js")
}
# Function an Distribution anhängen
resource "aws_cloudfront_distribution" "main" {
default_cache_behavior {
function_association {
event_type = "viewer-response"
function_arn = aws_cloudfront_function.csp_nonce.arn
}
}
}us-east-1 bereitgestellt. Verifizierung
Prüfen Sie den CSP-Header per curl. Bei dynamischen Nonces ändert sich der Nonce-Wert bei jedem Request. Erstellen Sie bei Bedarf eine CloudFront-Invalidierung, um gecachte Responses ohne CSP zu entfernen.
# CSP-Header prüfen
curl -sI https://ihre-domain.de | grep -i content-security-policy
# Erwartete Ausgabe (mit Nonce):
content-security-policy: default-src 'self'; script-src 'self' 'nonce-a1b2c3d4e5f6g7h8i9j0k1l2' 'strict-dynamic'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'
# Nonce ändert sich bei jedem Request
curl -sI https://ihre-domain.de | grep -i content-security-policy
content-security-policy: ... 'nonce-m3n4o5p6q7r8s9t0u1v2w3x4' ...Häufige Fehler
CSP in Policy UND Function gesetzt
Wenn sowohl die Response Headers Policy als auch die CloudFront Function den CSP-Header setzen, werden zwei CSP-Header gesendet. Der Browser wendet beide an — die restriktivere gewinnt. Setzen Sie CSP nur an einer Stelle.
Nonce stimmt nicht mit HTML überein
Die CloudFront Function setzt den Nonce im HTTP-Header, aber das HTML enthält keinen passenden nonce-Attribut. Lösung: Entweder SSR-Rendering mit Nonce-Injection oder 'strict-dynamic' nutzen, das die Nonce-Vererbung aktiviert.
10-KB-Limit der CloudFront Function überschritten
Komplexe CSPs mit vielen Domain-Allowlists können das 10-KB-Limit sprengen. Konsolidieren Sie Domains oder wechseln Sie zu Lambda@Edge (beachten Sie: nur in us-east-1).
Viewer-Response statt Origin-Response gewählt
CloudFront Functions unterstützen nur Viewer-Request und Viewer-Response Events. Für CSP-Nonces benötigen Sie das Viewer-Response Event. Origin-Response ist nur für Lambda@Edge verfügbar.
Compliance-Relevanz
CSP ist seit PCI DSS 4.0 (Requirement 6.4.3, Deadline März 2025) eine explizite Anforderung für alle Websites, die Kreditkartendaten verarbeiten. OWASP Top 10 empfiehlt CSP als Mitigation gegen A03:2021 Injection. NIS2 fordert technische Maßnahmen zum Schutz vor Cyberangriffen — CSP ist eine der wirksamsten. Der Wolf-Agents Web Security Check prüft CSP-Konfigurationen inklusive Nonce-Validierung und strict-dynamic-Support.
Wie steht Ihre Domain bei CSP?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.