security.txt prüfen

Was ist security.txt?

security.txt ist eine kleine Textdatei, die sagt, wie man dir eine Sicherheitslücke meldet. Die IETF hat das Format 2022 als RFC 9116 standardisiert. Die Datei liegt immer an derselben Stelle, unter https://beispiel.de/.well-known/security.txt, und nennt mindestens eine Kontaktadresse und ein Ablaufdatum.

Ohne diese Datei suchen Sicherheitsforscher auf gut Glück: Die Meldung landet im Kontaktformular des Vertriebs, beim Impressum, im Spam oder bleibt ganz aus. Im ungünstigsten Fall wird die Lücke veröffentlicht, weil niemand erreichbar war. Eine gepflegte security.txt kostet fünf Minuten und macht aus einem Zufall einen festen Meldeweg.

Aufbau der Datei

Jede Zeile ist ein Feld mit Namen und Wert, Kommentare beginnen mit #. Zwei Felder sind Pflicht, der Rest ist optional:

• Contact (Pflicht): E-Mail-Adresse mit mailto:, Telefonnummer mit tel: oder ein Meldeformular mit https://. Mehrere Zeilen sind erlaubt, die erste gilt als bevorzugt.
• Expires (Pflicht, genau einmal): Datum nach RFC 3339, bis zu dem die Angaben gelten. Empfohlen ist weniger als ein Jahr in der Zukunft. Danach sollen Forscher die Datei ignorieren.
• Encryption: Adresse des öffentlichen Schlüssels für verschlüsselte Meldungen.
• Policy: Adresse der Richtlinie zum Umgang mit Meldungen (Vulnerability Disclosure Policy).
• Preferred-Languages: Sprachen, in denen Meldungen willkommen sind, etwa „de, en“.
• Canonical: Die Adresse(n), unter denen diese Datei gilt. Wichtig vor allem bei signierten Dateien.
• Acknowledgments und Hiring: Danksagungen an Melder und Stellenangebote im Sicherheitsbereich.

Contact: mailto:security@beispiel.de
Contact: https://beispiel.de/sicherheit
Expires: 2027-06-30T22:00:00.000Z
Encryption: https://beispiel.de/pgp-key.txt
Preferred-Languages: de, en
Canonical: https://beispiel.de/.well-known/security.txt
Policy: https://beispiel.de/sicherheit/richtlinie

So liest du das Ergebnis

Der Checker unterscheidet zwischen Fehlern, durch die die Datei nicht gilt, und Abweichungen, die sie nur unsauber machen:

• Keine Datei: Hinweis, kein Fehler. Die meisten Domains haben (noch) keine security.txt.
• Contact oder Expires fehlt, Expires ist unlesbar oder die Datei kommt über HTTP: Die Datei ist nach RFC 9116 ungültig und damit wirkungslos.
• Abgelaufen: Forscher sollen eine abgelaufene Datei ignorieren. Läuft sie in den nächsten 30 Tagen ab, warnt der Checker schon vorher.
• Content-Type nicht text/plain, alter Ort /security.txt, Kontakt ohne mailto: oder https://, unlesbare Zeilen, Canonical zeigt woandershin: Hinweise, die Datei bleibt lesbar.
• Signiert: Eine OpenPGP-Signatur wird erkannt und nur der signierte Text ausgewertet. Die Signatur selbst prüft der Checker nicht.

Häufige Fehler

• Expires vergessen: Die Datei wurde einmal angelegt und ist nach einem Jahr stillschweigend abgelaufen. Der mit Abstand häufigste Fehler.
• Datum im falschen Format: „31.12.2026“ oder „Dec 31, 2026“ sind kein RFC-3339-Datum. Richtig ist 2026-12-31T23:00:00.000Z.
• Die Startseite statt der Datei: Viele Single-Page-Apps und Baukästen beantworten jede Adresse mit der Startseite und Status 200. Der Checker erkennt HTML und wertet das als „keine Datei“.
• E-Mail ohne mailto: Die Adresse steht als „security@beispiel.de“ statt „mailto:security@beispiel.de“ in der Datei.
• Postfach, das niemand liest: Die Datei ist nur so gut wie die Adresse darin. security@ muss bei jemandem ankommen, der weiß, was zu tun ist.

security.txt dauerhaft überwachen

Durch das Pflichtfeld Expires ist security.txt keine Datei, die man einmal anlegt und vergisst. DomainWarn prüft sie täglich für jede Kundendomain, meldet 30 Tage vor dem Ablauf, bei Ablauf und bei einer ungültigen Datei einen Vorfall und zeigt in der Zeitleiste, wenn die Datei verschwindet oder sich der Sicherheitskontakt ändert. Gerade Letzteres fällt sonst niemandem auf.

Häufige Fragen

Ist security.txt Pflicht?

Gesetzlich nicht. Die NIS2-Richtlinie zählt den Umgang mit Schwachstellen und ihre Offenlegung aber ausdrücklich zu den Maßnahmen, die betroffene Unternehmen umsetzen müssen. Eine security.txt ist der einfachste sichtbare Baustein dafür: Sie sagt, wo Meldungen ankommen.

Gilt die Datei auch für Subdomains?

Nein. Nach RFC 9116 gilt eine security.txt nur für den Host, unter dem sie abgerufen wurde. shop.beispiel.de braucht eine eigene Datei. Leitet die Subdomain auf eine zentrale Datei weiter, sollte diese die Adresse der Subdomain als Canonical aufführen. Der Checker prüft genau den Host, den du eingibst.

Muss ich die Datei signieren?

Nein, die RFC empfiehlt es nur. Wer signiert, sollte auch Canonical setzen und die Datei nach jeder Änderung neu signieren, auch nach dem Verlängern von Expires. Der Checker erkennt die Signatur, prüft sie aber nicht.

Welches Ablaufdatum soll ich setzen?

Weniger als ein Jahr in der Zukunft, wie von der RFC empfohlen. Bewährt haben sich sechs bis zwölf Monate mit einer Erinnerung im Kalender, oder eine Überwachung, die rechtzeitig vor dem Ablauf meldet.