Security-Header-Architektur für AWS CloudFront
Alle Security Headers zentral per Terraform und CloudFront Functions verwalten — Response Headers Policies für statische Header, Functions für dynamische Nonces.
Multi-Layer-Architektur für CloudFront Security Headers
AWS CloudFront bietet eine zweistufige Architektur für Security Headers. Response Headers Policies decken alle statischen Header ab — HSTS, X-Frame-Options, Referrer-Policy und X-Content-Type-Options. Für dynamische Header wie CSP-Nonces oder Reporting-Endpoints setzen Sie CloudFront Functions ein. Diese Trennung macht den Wolf-Agents Web Security Check zur idealen Validierung.
Die AWS-Managed SecurityHeadersPolicy setzt HSTS ohne includeSubDomains und ohne preload, enthält keine CSP und keine Permissions-Policy. Für produktive Systeme erstellen Sie daher immer eine eigene Policy. Unsere Terraform-Konfiguration unten enthält alle relevanten Header.
Response Headers Policy per Terraform erstellen
Die Response Headers Policy ist die zentrale Konfiguration für alle statischen Security Headers. Terraform ermöglicht versionierte, nachvollziehbare Änderungen. Die Policy wird anschließend an ein oder mehrere Behaviors der Distribution angehängt.
# terraform/cloudfront-security-headers.tf
resource "aws_cloudfront_response_headers_policy" "security_headers" {
name = "security-headers-policy"
comment = "Alle Security Headers für Produktion"
security_headers_config {
strict_transport_security {
access_control_max_age_sec = 31536000
include_subdomains = true
preload = true
override = true
}
content_type_options {
override = true
}
frame_options {
frame_option = "DENY"
override = true
}
referrer_policy {
referrer_policy = "strict-origin-when-cross-origin"
override = true
}
xss_protection {
mode_block = true
protection = true
override = true
}
}
custom_headers_config {
items {
header = "Permissions-Policy"
value = "camera=(), microphone=(), geolocation=(), payment=()"
override = true
}
items {
header = "X-DNS-Prefetch-Control"
value = "off"
override = true
}
}
}
# Policy an Distribution anhängen
resource "aws_cloudfront_distribution" "main" {
default_cache_behavior {
response_headers_policy_id = aws_cloudfront_response_headers_policy.security_headers.id
# ... weitere Konfiguration
}
}override = true? Ohne override = true setzt CloudFront den Header nur, wenn der Origin keinen gleichnamigen Header sendet. Mit override = true überschreibt die Policy den Origin-Header — wichtig, wenn Ihr ALB oder Ihre Lambda-Funktion bereits Header setzt.
CloudFront Function für dynamische Header
Dynamische Header wie CSP mit Nonces erfordern eine CloudFront Function im Viewer-Response Event. Die Function läuft auf allen Edge Locations, generiert pro Request einen zufälligen Nonce und fügt den CSP-Header ein. Das 10-KB-Code-Limit ist für diese Aufgabe ausreichend.
// CloudFront Function — Viewer Response Event
// Dynamische Header (CSP mit Nonce, Reporting)
function handler(event) {
var response = event.response;
var headers = response.headers;
// CSP mit dynamischem Nonce
var nonce = crypto.randomUUID().replace(/-/g, '').substring(0, 24);
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:; "
+ "object-src 'none'; "
+ "base-uri 'self'"
};
// Reporting Endpoints
headers['reporting-endpoints'] = {
value: 'csp-endpoint="https://ihre-domain.de/api/csp-report"'
};
return response;
}us-east-1 bereitgestellt wird. Verifizierung
Nach dem Deployment prüfen Sie alle Header mit curl. Bei Änderungen an der Response Headers Policy kann eine CloudFront-Invalidierung nötig sein, damit die neuen Header sofort an allen Edge Locations aktiv sind.
# Alle Security Headers prüfen
curl -sI https://ihre-domain.de | grep -iE "strict-transport|content-security|x-frame|referrer-policy|x-content-type|permissions-policy"
# Erwartete Ausgabe:
strict-transport-security: max-age=31536000; includeSubDomains; preload
content-security-policy: default-src 'self'; script-src 'self' 'nonce-...' 'strict-dynamic'; ...
x-frame-options: DENY
referrer-policy: strict-origin-when-cross-origin
x-content-type-options: nosniff
permissions-policy: camera=(), microphone=(), geolocation=(), payment=()Häufige Fehler
Response Headers Policy nicht an Behavior gebunden
Die Policy existiert, ist aber keinem Behavior zugewiesen. Prüfen Sie im Distribution-Editor, dass response_headers_policy_id im Default oder Custom Behavior gesetzt ist.
CloudFront Function und Policy setzen denselben Header
Wenn sowohl die Response Headers Policy als auch die CloudFront Function z.B. CSP setzen, werden beide Header gesendet. Setzen Sie CSP nur in der Function und alle anderen Header in der Policy.
Managed SecurityHeadersPolicy unvollständig
Die AWS-Managed Policy setzt HSTS ohne includeSubDomains und ohne preload. Sie enthält weder CSP noch Permissions-Policy. Nutzen Sie immer eine Custom Policy.
Cache nicht invalidiert nach Policy-Änderung
Gecachte Responses enthalten die alten Header. Erstellen Sie eine Invalidierung (/*) oder warten Sie auf den TTL-Ablauf.
Compliance-Relevanz
Eine konsolidierte Header-Architektur ist Voraussetzung für PCI DSS 4.0 (Requirement 6.4.3 — CSP-Management) und erleichtert NIS2-Audits durch nachvollziehbare Terraform-Konfigurationen. SOC 2 Type II fordert dokumentierte Sicherheitskontrollen — Infrastructure as Code mit Terraform erfüllt diese Anforderung. Der Wolf-Agents Web Security Check validiert alle Header-Konfigurationen automatisch mit 166 Prüfpunkten.
Wie steht Ihre Domain bei Architektur?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.