security.txt-Generator und -Prüfer
Erstellen Sie eine gültige security.txt nach RFC 9116, damit Sicherheitsforschende wissen, wie sie Sie erreichen, oder fügen Sie eine vorhandene ein und sehen Sie, was daran nicht stimmt. Ein Baustein der Vorbereitung auf die EU-Cyberresilienz-Verordnung (Cyber Resilience Act, CRA).
Läuft vollständig in Ihrem Browser
security.txt erstellen
security.txt prüfen
Geprüft wird der Text ausschließlich gegen RFC 9116. Die Seite ruft Ihre Website nicht ab (was Sie eingeben, verlässt diese Seite nicht, fügen Sie die Datei deshalb ein), prüft keine OpenPGP-Signatur und testet nicht, ob eine Adresse funktioniert. Eine Vorlage, keine Rechtsberatung.
So erstellen und prüfen Sie eine security.txt
- Geben Sie mindestens einen Contact an (eine E-Mail-Adresse, eine Telefonnummer oder eine https://-Seite) und kontrollieren Sie das Datum bei Expires. Füllen Sie die optionalen Felder aus, die Sie brauchen, etwa Policy und Preferred-Languages.
- Kopieren Sie die Datei oder laden Sie sie herunter und veröffentlichen Sie sie unter
/.well-known/security.txtIhrer Domain, per HTTPS und als reinen Text. - Um eine vorhandene Datei zu prüfen, fügen Sie ihren Text in den Prüfer ein. Beheben Sie zuerst die Fehler und sehen Sie sich dann die Warnungen an. Tragen Sie die Adresse ein, unter der Sie die Datei bereitstellen, um das Feld Canonical zu testen.
- Legen Sie sich einen Termin im Kalender an, um Expires zu verlängern, bevor das Datum verstreicht.
Wofür eine security.txt gut ist
Wenn Sicherheitsforschende, Kunden oder ein CERT eine Schwachstelle in Ihrer Software finden, lautet das erste Problem: Wen informiert man? Eine security.txt beantwortet das. Es ist eine kleine Textdatei unter einer festen Adresse, /.well-known/security.txt, mit einem Kontakt, einem Ablaufdatum und optional einem Link auf Ihre Richtlinie zur Offenlegung und auf einen öffentlichen Schlüssel. RFC 9116 legt das Format fest, und viele Scanner, Bug-Bounty-Plattformen und nationale CERTs suchen zuerst nach dieser Datei.
Für Softwareanbieter in der EU unterstützt sie zugleich Pflichten aus der Cyberresilienz-Verordnung: Anhang I erwartet einen veröffentlichten Weg, auf dem Außenstehende Schwachstellen melden können, und einen Prozess, sie zu bearbeiten. Die Verordnung nennt dieses Format nicht, aber es ist der übliche Weg, den Kontakt zu veröffentlichen. Der Meldeleitfaden für kleine Anbieter beschreibt die übrige Einrichtung, einschließlich der 24-Stunden-Frist.
Die Felder
Contact und Expires sind Pflicht. Contact darf mehrfach vorkommen und muss ein URI sein: mailto:, tel: oder https:. Expires steht genau einmal, als Datum mit Uhrzeit wie 2027-12-31T23:59:59Z, und RFC 9116 verlangt weniger als ein Jahr im Voraus. Encryption, Acknowledgments, Policy, Hiring und Canonical sind optionale Links, und jede Webadresse muss https verwenden. Preferred-Languages steht einmal und listet Sprachcodes auf. Felder, die der RFC nicht definiert, ignorieren die lesenden Programme; der Prüfer meldet sie deshalb als Warnung, denn meistens sind es Tippfehler.
Tipps
- Nehmen Sie ein Postfach, das mehrere Personen lesen, nicht die Adresse einer einzelnen Person, und testen Sie es, indem Sie hineinschreiben.
- Verfassen Sie eine Richtlinie zur Offenlegung von Schwachstellen und verlinken Sie sie im Feld Policy.
- Kennen Sie Ihre Fristen, bevor eine Meldung eintrifft: Die CRA-24-Stunden-Meldeuhr macht aus dem Zeitpunkt der Kenntnis konkrete Fristen mit Datum.
Häufige Fragen
Verlangt die Cyberresilienz-Verordnung eine security.txt?
Nein. Die Verordnung erwartet von Herstellern eine Richtlinie zur koordinierten Offenlegung von Schwachstellen und einen veröffentlichten Weg, Schwachstellen zu melden. Eine security.txt ist die gängige Art, diesen Kontakt zu veröffentlichen, und wird in der Praxis empfohlen, das Format nennt die Verordnung aber nicht. Siehe den Leitfaden für kleine Anbieter.
Wo genau lege ich die Datei ab?
Unter https://ihre-domain/.well-known/security.txt, ausgeliefert per HTTPS mit dem Content-Type text/plain; charset=utf-8. RFC 9116 erlaubt für ältere Umgebungen außerdem eine Kopie unter /security.txt. Veröffentlichen Sie sie auf jeder Domain und Subdomain, die abgedeckt sein soll.
Wie weit in der Zukunft sollte Expires liegen?
Laut RFC 9116 weniger als ein Jahr, damit sich Forschende darauf verlassen können, dass die Kontaktdaten gepflegt werden. Der Generator schlägt ein Datum knapp unter einem Jahr vor. Nach Ablauf des Datums sollen Programme die Datei ignorieren, verlängern Sie sie also rechtzeitig.
Muss ich die Datei mit PGP signieren?
Nein, das Signieren ist optional, wird aber empfohlen. Eine signierte Datei ist eine OpenPGP-Nachricht mit Klartext-Signatur, erzeugt mit gpg --clearsign security.txt. Der Prüfer erkennt das signierte Format und prüft seinen Aufbau, die Signatur selbst kann er aber nicht verifizieren; verwenden Sie dafür gpg --verify.
Warum ruft der Prüfer meine Website nicht ab?
Damit die Seite privat bleibt: Sie läuft vollständig in Ihrem Browser und sendet keine Anfragen an andere Websites. Öffnen Sie Ihre Datei in einem Browser-Tab, kopieren Sie den Text und fügen Sie ihn ein. So prüfen Sie zugleich, was Besucher tatsächlich erhalten.
Wofür ist das Feld Canonical da?
Es listet die Adressen auf, unter denen die Datei bereitgestellt werden soll, damit sich ein Leser vergewissern kann, dass eine unter einer Adresse gefundene Datei auch dorthin gehört. Wenn Sie die Adresse eingeben, unter der Sie die Datei bereitstellen, prüft der Prüfer, ob eine Ihrer Canonical-Zeilen dazu passt.