security.txt für AWS CloudFront konfigurieren
security.txt im S3-Bucket unter .well-known/ ablegen und über CloudFront ausliefern — mit Terraform, AWS CLI und korrektem Content-Type.
security.txt auf AWS CloudFront
Die security.txt (RFC 9116) ist eine standardisierte Kontaktdatei für Sicherheitsforscher. Sie enthält Kontaktinformationen, bevorzugte Sprachen, einen Ablaufzeitpunkt und optional einen PGP-Schlüssel für verschlüsselte Kommunikation. Die security.txt ist mit 2 von 166 Punkten ein kleiner, aber einfach umzusetzender Faktor im Wolf-Agents Web Security Check.
Bei AWS CloudFront mit S3-Origin legen Sie die Datei direkt im S3-Bucket unter .well-known/security.txt ab. CloudFront leitet Requests an diesen Pfad automatisch an den S3-Origin weiter — keine spezielle Konfiguration nötig. Entscheidend ist der korrekte Content-Type: S3 setzt standardmäßig application/octet-stream für unbekannte Dateitypen, was die Anzeige im Browser verhindert.
Wichtig: Die Felder Contact und Expires sind nach RFC 9116 Pflicht. Das Expires-Datum sollte maximal 1 Jahr in der Zukunft liegen. Aktualisieren Sie die Datei jährlich — ein abgelaufenes Expires-Datum signalisiert mangelnde Wartung und reduziert das Vertrauen.
security.txt nach RFC 9116 erstellen
Erstellen Sie die security.txt mit den Pflichtfeldern Contact (mailto: oder https:-URL) und Expires (ISO 8601 Zeitstempel). Optionale Felder wie Preferred-Languages, Canonical, Policy und Encryption erhöhen die Professionalität und Vertrauenswürdigkeit.
# .well-known/security.txt — RFC 9116
Contact: mailto:security@ihre-domain.de
Expires: 2027-03-29T00:00:00.000Z
Preferred-Languages: de, en
Canonical: https://ihre-domain.de/.well-known/security.txt
Policy: https://ihre-domain.de/security-policy
Encryption: https://ihre-domain.de/.well-known/pgp-key.txtDatei nach S3 hochladen
Laden Sie die Datei mit dem korrekten Content-Type text/plain; charset=utf-8 nach S3 hoch. Per AWS CLI für schnelle Uploads oder per Terraform für Infrastructure-as-Code — beide Wege sind vollständig automatisierbar und reproduzierbar.
# security.txt per AWS CLI nach S3 hochladen
aws s3 cp security.txt \
s3://ihr-bucket/.well-known/security.txt \
--content-type "text/plain; charset=utf-8" \
--cache-control "public, max-age=86400"# terraform/security-txt.tf — S3 Object
resource "aws_s3_object" "security_txt" {
bucket = aws_s3_bucket.website.id
key = ".well-known/security.txt"
source = "files/security.txt"
content_type = "text/plain; charset=utf-8"
etag = filemd5("files/security.txt")
cache_control = "public, max-age=86400"
}
# Optional: PGP-Schlüssel bereitstellen
resource "aws_s3_object" "pgp_key" {
bucket = aws_s3_bucket.website.id
key = ".well-known/pgp-key.txt"
source = "files/pgp-key.txt"
content_type = "text/plain; charset=utf-8"
etag = filemd5("files/pgp-key.txt")
}CloudFront-Konfiguration prüfen
Bei einer Standard-CloudFront-Distribution mit S3-Origin werden alle Pfade an den Bucket weitergeleitet — auch .well-known/. Wenn Ihre Bucket-Policy nur bestimmte Pfade erlaubt, müssen Sie .well-known/* zur Allow-Liste hinzufügen. Bei Nutzung einer CloudFront Origin Access Identity (OAI) oder Origin Access Control (OAC) ist der Zugriff automatisch konfiguriert.
Wenn Sie die security.txt aktualisieren (z.B. neues Expires-Datum), kann CloudFront die alte Version noch aus dem Cache ausliefern. Erstellen Sie eine Invalidierung: aws cloudfront create-invalidation --distribution-id E1234 --paths "/.well-known/security.txt".
Verifizierung
Prüfen Sie die security.txt per curl. Die Datei muss unter /.well-known/security.txt erreichbar sein, den korrekten Content-Type text/plain; charset=utf-8 haben und ein gültiges Expires-Datum enthalten. Der Wolf-Agents Web Security Check prüft Existenz, Erreichbarkeit und Gültigkeit der security.txt automatisch.
# security.txt prüfen
curl -s https://ihre-domain.de/.well-known/security.txt
# Erwartete Ausgabe:
Contact: mailto:security@ihre-domain.de
Expires: 2027-03-29T00:00:00.000Z
Preferred-Languages: de, en
Canonical: https://ihre-domain.de/.well-known/security.txt
Policy: https://ihre-domain.de/security-policy
# Content-Type prüfen
curl -sI https://ihre-domain.de/.well-known/security.txt | grep -i content-type
# Erwartete Ausgabe:
content-type: text/plain; charset=utf-8Häufige Fehler
Falscher Content-Type
S3 setzt standardmäßig application/octet-stream für Dateien ohne Erweiterungszuordnung. Setzen Sie explizit text/plain; charset=utf-8 beim Upload — sonst wird die Datei heruntergeladen statt im Browser angezeigt.
S3-Bucket-Policy blockiert .well-known/
Wenn Ihre S3-Bucket-Policy nur bestimmte Pfade erlaubt (z.B. nur /index.html und /assets/), fügen Sie .well-known/* zur Allow-Liste hinzu. Bei OAI/OAC entfällt dieses Problem.
Expires-Datum abgelaufen
Sicherheitsforscher und automatisierte Tools prüfen das Expires-Datum. Eine abgelaufene security.txt signalisiert mangelnde Wartung und wird von einigen Tools als ungültig gewertet. Aktualisieren Sie das Datum jährlich.
Canonical-URL stimmt nicht überein
Das Canonical-Feld muss exakt mit der URL übereinstimmen, unter der die Datei erreichbar ist. Stellen Sie sicher, dass HTTPS, Domain (mit/ohne www) und Pfad korrekt sind.
Compliance-Relevanz
ISO 27001 (A.6.1.3) fordert einen dokumentierten Kontaktweg für Sicherheitsvorfälle — die security.txt erfüllt diese Anforderung auf standardisierte Weise. BSI IT-Grundschutz empfiehlt eine veröffentlichte Kontaktmöglichkeit für Security-Researcher, die Schwachstellen melden möchten. NIS2 fordert definierte Meldewege für Cybervorfälle — die security.txt ist der anerkannte Standard dafür. DSGVO erfordert Transparenz — eine öffentliche Security-Policy und Kontaktdaten schaffen Vertrauen. Der Wolf-Agents Web Security Check prüft Existenz und Gültigkeit der security.txt.
Wie steht Ihre Domain bei security.txt?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.