So funktioniert’s
Die Datei liegt unter https://example.com/.well-known/security.txt und nennt den Meldeweg für Sicherheitslücken. Pflicht sind zwei Felder: Contact (eine mailto:-, tel:- oder https:-Adresse) und Expires, ein Datum nach RFC 3339, das laut RFC weniger als ein Jahr in der Zukunft liegen soll.
Optional kommen Encryption (ein öffentlicher Schlüssel), Policy (die Regeln für Meldungen), Acknowledgments, Preferred-Languages, Hiring und Canonical (die Adressen, unter denen die Datei gilt) dazu. Ausgeliefert wird sie als text/plain über HTTPS; sie darf mit OpenPGP signiert sein.
Nach Ablauf von Expires sollen Forscher die Datei ignorieren. Genau daran scheitern viele Dateien: einmal angelegt, nie wieder angefasst.
Warum gefährlich
Ohne security.txt suchen Finder einer Lücke im Impressum, schreiben an eine allgemeine Adresse oder geben auf. Die Meldung landet im Spam oder bei jemandem, der sie nicht einordnen kann, und die Lücke bleibt offen, bis sie jemand anderes ausnutzt.
Eine abgelaufene oder fehlerhafte Datei ist kaum besser: Sie signalisiert, dass sich niemand kümmert, und schickt Meldungen womöglich an Adressen, die es nicht mehr gibt.
So vermeidest du es
- Die Datei unter /.well-known/security.txt mit mindestens Contact und Expires anlegen, etwa Contact: mailto:security@example.com und Expires: 2027-06-30T23:00:00.000Z.
- Ein Postfach wie security@ verwenden, das mehrere Personen lesen, statt einer persönlichen Adresse.
- Expires höchstens ein Jahr vorausdatieren und einen Termin zur Erneuerung einplanen – oder die Datei von einem Dienst ausliefern lassen, der Expires automatisch nachzieht.
- Die Datei als text/plain über HTTPS ausliefern, ohne Weiterleitung auf http://.
- Eine Policy-Seite verlinken, die beschreibt, was gemeldet werden soll und wann mit einer Antwort zu rechnen ist.
So erkennt DomainWarn es
Der Check „security.txt“ ruft täglich /.well-known/security.txt ab (ersatzweise den alten Ort /security.txt) und prüft die Datei nach RFC 9116. Fehlt sie, ist das ein Hinweis. Fehlen Contact oder Expires, ist das Datum unlesbar oder kommt die Datei über HTTP, eröffnet das den Incident „security.txt ungültig“; eine abgelaufene Datei führt zu „security.txt abgelaufen“, ein Ablauf in den nächsten 30 Tagen zu „security.txt läuft bald ab“.
Falscher Content-Type, der alte Ort, unlesbare Zeilen, ein doppeltes Expires, ein Ablauf mehr als ein Jahr voraus und eine abweichende Canonical-Angabe sind Hinweise. Eine OpenPGP-Signatur erkennt DomainWarn, prüft sie aber nicht. Auf Wunsch erzeugt DomainWarn die Datei selbst und hält Expires aktuell.
DomainWarn prüft das für alle deine Domains regelmäßig und meldet sich, wenn etwas fehlt oder sich ändert.