security.txt-Validator
Fügen Sie den Inhalt Ihrer security.txt (RFC 9116) ein, um Syntaxfehler zu erkennen. Prüft Pflichtfelder wie Contact und Expires sowie deren Werteformat, damit Sie bestätigen können, dass die Datei korrekt unter /.well-known/security.txt veröffentlicht ist.
Das Format einer security.txt prüfen
Eine security.txt ist jene Textdatei, mit der eine Website denjenigen, die eine Schwachstelle gefunden haben, mitteilt, wohin sie sich wenden sollen; ihr Format legt RFC 9116 fest. Fügen Sie den Inhalt ein, und dieses Werkzeug prüft die Syntax und bestätigt, dass Pflichtfelder wie `Contact` und `Expires` vorhanden sind und ihre Werte die gebotene Form haben.
**Leicht übersehen wird hier der Umgang mit `Expires`.** Es ist nicht nur ein Pflichtfeld, sondern **eine Datei, deren genannter Zeitpunkt verstrichen ist, gilt als nicht mehr gültig.** Wer sie einmal veröffentlicht und sich nicht weiter darum kümmert, hat nach einigen Jahren eine Datei, die zwar da, aber wirkungslos ist; sie will daher zusammen mit einem Plan zur Erneuerung geführt sein. **Auch ihr Ort steht fest: Sie gehört nach `/.well-known/security.txt`.** Ist die Datei signiert, nennt das Feld `Canonical` die maßgebliche Adresse, damit Lesende sich vergewissern können, dass niemand an ihr gerührt hat.
So gehen Sie vor
- Fügen Sie den Inhalt Ihrer security.txt ein Geben Sie die ganze Datei unverändert ein.
- Probieren Sie zuerst die Beispiele Ein gültiges Beispiel und eines mit Fehlern liegen beide bereit.
- Lesen Sie die genannten Punkte **Fehlende Pflichtfelder und falsch geformte Werte werden beide gemeldet.**
- Prüfen Sie den in `Expires` genannten Zeitpunkt **Bestätigen Sie, dass er nicht in der Vergangenheit liegt, und legen Sie vorab fest, wann Sie erneuern.**
Tipps für die Nutzung
- Der offizielle Ablageort für security.txt ist
/.well-known/security.txt. Aus Kompatibilitätsgründen lohnt es sich, zusätzlich eine Kopie unter/security.txt(im Website-Root) zu veröffentlichen. - Schreiben Sie Contact als URI mit Schema, etwa mailto:, https: oder tel:. Eine reine E-Mail-Adresse entspricht nicht RFC 9116 und wird von automatischen Parsern womöglich nicht erkannt.
- Setzen Sie Expires auf höchstens ein Jahr in der Zukunft und verlängern Sie es bei jeder Erneuerung. Eine abgelaufene Datei riskiert, als verwaister, ungepflegter Kontakt zu gelten.
- Die gesamte Prüfung in diesem Tool läuft vollständig im Browser ab — nichts von dem, was Sie einfügen, wird an einen Server gesendet, sodass Sie eine Datei bedenkenlos vor der Veröffentlichung prüfen können.
Wofür Sie es nutzen können
Um Ihre Sicherheitsanlaufstelle klar zu benennen
Wer etwas findet, muss keine Adresse suchen, und eine Meldung erreicht Sie weit eher.
Um das Veröffentlichte zu prüfen
**Eine falsch geformte Datei gibt nach außen kein Zeichen, sodass nichts außer einer Prüfung sie aufdeckt.**
Um dem Ablauf vorzubeugen
Sie können in Abständen nachsehen, ob `Expires` nicht verstrichen ist.
Um im Unternehmen einen Standard zu halten
Werden mehrere Websites gemeinsam betrieben, lässt sich bestätigen, dass alle demselben Format folgen.
Begriffe zur security.txt
- Contact
- Ein **Pflichtfeld**, das einen Weg zur Kontaktaufnahme nennt: eine E-Post-Adresse, eine Rufnummer oder die Adresse eines Meldeformulars.
- Expires
- Ein **Pflichtfeld**, nach dessen genanntem Zeitpunkt die Datei als nicht mehr gültig gilt.
- Encryption
- Verweist auf einen öffentlichen Schlüssel, mit dem sich eine Meldung verschlüsseln lässt.
- Policy
- Die Adresse einer Seite, die die Grundsätze zur Offenlegung von Schwachstellen darlegt.
- Canonical
- Die maßgebliche Adresse, unter der diese Datei liegen soll. **Gegen sie wird eine Signatur geprüft.**
- Preferred-Languages
- Nennt die Sprachen, in denen Meldungen entgegengenommen werden können, durch Kommas getrennt wie in `en, ja`.
Häufig gestellte Fragen
https://example.com/.well-known/security.txt als offiziellen Ort fest. Da viele Implementierungen auch den älteren Pfad https://example.com/security.txt prüfen, wird empfohlen, sie aus Kompatibilitätsgründen an beiden Orten zu veröffentlichen.mailto:[email protected] erforderlich ist. Ohne Schema erkennen automatische Parser den Wert womöglich nicht korrekt.
Übrigens – Die Entstehung von security.txt – der "erste Anlaufpunkt", den ein Bug-Bounty-Programm allein nicht bieten konnte
security.txt wurde 2017 von den Sicherheitsforschern Ed Overflow und Kagan Baytas vorgeschlagen. Damals hatten Forscher, die eine Sicherheitslücke fanden, oft keinen klaren Weg, sie zu melden, und mussten auf ein allgemeines Kontaktformular oder eine Direktnachricht in sozialen Netzwerken zurückgreifen. Meldungen brauchten häufig lange, bis sie die richtige Person erreichten, oder wurden schlicht ignoriert.
Der Vorschlag wurde bei der IETF (Internet Engineering Task Force) eingereicht und wurde nach Jahren der Diskussion und Überarbeitung 2022 offiziell als RFC 9116 standardisiert. Der Mechanismus ist einfach: Der Website-Betreiber veröffentlicht eine einzige Textdatei unter /.well-known/security.txt, und Forscher können mechanisch ermitteln, wen sie kontaktieren sollen, in welcher Sprache und nach welcher Richtlinie.
Große Technologieunternehmen wie GitHub, Google, Facebook und LinkedIn haben security.txt übernommen, und es ist üblich, über das Policy-Feld einen Link zu einem Programm für die Offenlegung von Schwachstellen oder einem Bug-Bounty-Programm anzugeben. Es dient praktisch als "Eingangstür", die Forscher erreicht, die eine Bug-Bounty-Plattform sonst vielleicht nie gefunden hätten.
Als natürliche Erweiterung von RFC 9116 verlinken immer mehr Organisationen über das CSAF-Feld auf CSAF-Dokumente (Common Security Advisory Framework) und standardisieren so den Austausch von Sicherheitshinweisen. security.txt ist längst mehr als nur eine Kontaktdatei und entwickelt sich weiter zum Einstiegspunkt für den gesamten Sicherheitsreaktionsprozess einer Organisation.