RFC 9116 standardisiert Sicherheitskontaktinformationen, aber viele Implementierungen machen die Details falsch. Lerne was du für eine ordnungsgemäße Implementierung wissen musst.
RFC 9116 standardisiert, wie Organisationen Sicherheitskontaktinformationen veröffentlichen sollen. Trotz der Einfachheit einer Textdatei machen viele Implementierungen die Details falsch. Dieser Leitfaden erklärt, was du wissen musst.
Der security.txt-Standard bietet einen konsistenten Weg für Security-Forscher, Kontaktinformationen zu finden, wenn sie Schwachstellen entdecken. Es ist eine maschinenlesbare Datei, die unter /.well-known/security.txt auf deiner Domain platziert wird.
Die Spezifikation ist absichtlich minimal. Eine grundlegende security.txt-Datei enthält nur wenige Felder, aber diese Felder haben spezifische Anforderungen, die oft übersehen werden.
Nur ein Feld ist strikt erforderlich: Contact. Alles andere ist optional, wenn auch empfohlen. Eine minimal gültige Datei sieht so aus:
Contact: mailto:[email protected]
Expires: 2026-12-31T23:59:59Z
Das Expires-Feld ist technisch nicht von der Spezifikation gefordert, wird aber stark empfohlen. Ohne dieses wissen Forscher nicht, ob die Kontaktinformation noch gültig ist.
Das Expires-Feld muss das RFC 3339 Format verwenden: YYYY-MM-DDTHH:MM:SSZ. Ich sehe regelmäßig Formate wie 31.12.2026 oder 2026-12-31, die beide ungültig sind. Das korrekte Format beinhaltet den vollständigen Zeitstempel mit Zeitzonenangabe.
Wenn du ein Webformular für Kontakt verwendest, muss es HTTPS sein. HTTP-URLs sind von der Spezifikation nicht erlaubt. Das stellt sicher, dass Forscher dich über einen sicheren Kanal kontaktieren.
Die Datei muss unter /.well-known/security.txt liegen. Sie unter /security.txt zu platzieren verletzt die Spezifikation. Beide Orte sind erlaubt, aber der well-known-Ort ist als primäre Quelle erforderlich.
Über das Minimum hinaus verbessern mehrere optionale Felder die Nutzbarkeit. Das Preferred-Languages-Feld teilt Forschern mit, welche Sprachen dein Team spricht, wie Preferred-Languages: de, en, fr. Das hilft Forschern, Issues in einer Sprache zu melden, die dein Team versteht.
Das Canonical-Feld spezifiziert, wo diese Datei zu finden sein sollte: Canonical: https://example.com/.well-known/security.txt. Das verhindert Verwirrung, wenn deine security.txt anderswo gespiegelt oder gecacht wird.
Das Policy-Feld verlinkt zu deiner vollständigen Vulnerability Disclosure Policy. Hier erklärst du deine Disclosure-Timeline, was im Scope ist und welche Regeln Forscher befolgen sollen. Die meisten Organisationen finden das nützlicher, als alles in security.txt zu packen.
Die Spezifikation erlaubt PGP-Signaturen, aber in der Praxis schaffen sie mehr Probleme als sie lösen. Die meisten Forscher verifizieren die Signaturen nicht, und gültige PGP-Keys zu pflegen erfordert laufende Arbeit, die wenige Security-Teams priorisieren.
Wenn du deine security.txt signierst, stelle sicher, dass dein Key nicht vor deiner security.txt abläuft. Ich habe Dateien gesehen, wo die Signatur sechs Monate vor dem Contact-Feld abläuft, was den Zweck völlig verfehlt.
Setze dein Ablaufdatum basierend darauf, wie oft du die Datei realistisch überprüfen und aktualisieren kannst. Ein Jahr ist üblich, aber sechs Monate sind sicherer, wenn sich dein Security-Kontakt häufig ändert. Corporate-E-Mail-Adressen werden neu vergeben, Teams reorganisieren sich, und Sicherheitsverantwortlichkeiten verschieben sich. Regelmäßige Reviews fangen diese Änderungen auf, bevor Forscher Reports an inaktive Adressen senden.
Wenn das Ablaufdatum näher rückt, aktualisiere die Datei mit einem neuen Datum. Lass sie nicht ablaufen. Abgelaufene security.txt-Dateien sind schlechter als keine security.txt-Datei, weil sie Vernachlässigung signalisieren.
Nach dem Erstellen deiner security.txt, besuche https://deinedomäne.de/.well-known/security.txt und verifiziere, dass sie korrekt lädt. Prüfe die Syntax auf https://securitytxt.org/, einem Community-Validator, der häufige Fehler erkennt. Verifiziere, dass alle URLs funktionieren und HTTPS verwenden. Bestätige, dass das Datumsformat korrekt ist. Am wichtigsten: Teste, dass E-Mail-Adressen tatsächlich dein Security-Team erreichen.
Dein Webserver sollte security.txt mit Content-Type: text/plain; charset=utf-8 ausliefern. Die meisten Server tun das automatisch für .txt-Dateien, aber verifiziere es mit curl -I https://deinedomäne.de/.well-known/security.txt. Die Antwort sollte den korrekten Content-Type-Header enthalten.
Hier ist eine vollständige, korrekt formatierte security.txt mit allen empfohlenen Feldern:
Contact: mailto:[email protected]
Contact: https://example.com/security-report
Expires: 2026-12-31T23:59:59Z
Preferred-Languages: de, en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policy
Acknowledgments: https://example.com/security-acknowledgments
Beachte, dass du mehrere Contact-Felder angeben kannst. Das gibt Forschern Optionen, falls ein Kanal für sie nicht funktioniert.
Setze eine Kalendererinnerung einen Monat vor deinem Ablaufdatum. Das gibt dir Zeit, die Datei zu überprüfen und zu aktualisieren, bevor sie abläuft. Prüfe, dass Kontaktadressen noch funktionieren, dass deine Policy-URL sich nicht geändert hat, und dass dein Team noch die gelisteten Sprachen spricht.
Wenn sich dein Security-Kontakt ändert, aktualisiere security.txt sofort. Forscher, die der Spezifikation folgen, werden dies als ihre primäre Kontaktmethode nutzen. Reports ins Leere zu senden, weil deine security.txt veraltet ist, verschwendet die Zeit aller.
Die Spezifikation definiert nicht, was passiert, nachdem ein Forscher dich kontaktiert hat. Sie spezifiziert keine Antwortzeiten, Disclosure-Timelines oder Bounty-Zahlungen. Diese gehören in dein vollständiges Security-Policy-Dokument, verlinkt vom Policy-Feld.
Denke an security.txt als Wegweiser. Es sagt Forschern, wohin sie Reports senden sollen, aber der eigentliche Vulnerability-Disclosure-Prozess ist separat. Versuche nicht, deine gesamte Security-Policy in diese Datei zu packen.
Große Organisationen wie Google, GitHub und Amazon haben security.txt implementiert. Browser-Hersteller beginnen danach zu suchen, wenn User Sicherheitsprobleme melden. Einige Vulnerability-Scanner prüfen nun dessen Vorhandensein als grundlegenden Security-Hygiene-Indikator.
Die Implementierungskosten sind minimal. Es ist buchstäblich eine Textdatei, die zehn Minuten zum Erstellen und Hosten braucht. Der Wert ist klar: Forscher wissen genau, wie sie dich erreichen können, wenn sie Probleme finden. In einer Welt, in der das Finden des richtigen Security-Kontakts oft Detektivarbeit erfordert, löst dieser Standard ein echtes Problem.
Ein technischer Vergleich von Vulnerability Disclosure Ansätzen von security.txt bis zu Full Bug Bounty Plattformen. Die Security Trade-offs auf jeder Reifestufe verstehen.
Ein technischer Vergleich von Vulnerability Disclosure Ansätzen von security.txt bis zu Full Bug Bounty Plattformen. Die Security Trade-offs auf jeder Reifestufe verstehen.
Klarer Scope in deiner Vulnerability-Disclosure-Policy bestimmt, was Forscher testen sollen. Mach es falsch und du wirst valide Research entmutigen oder mit ungewolltem Testing umgehen müssen.
Get the latest security research insights and vulnerability disclosure best practices delivered to your inbox.