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