security.txt Generator nach RFC 9116

Wie funktioniert dieses Tool?

1. Kontaktwege eintragen. Trage in das Feld Contact jede Meldeadresse in eine eigene Zeile ein – die wichtigste zuerst. E-Mail-Adressen und Telefonnummern werden automatisch in die vom Standard geforderte URI-Form (mailto:, tel:) gebracht.
2. Ablaufdatum setzen. Expires ist vorbelegt mit einem Jahr ab heute. Das ist der vom RFC empfohlene Rahmen: lang genug für den Alltag, kurz genug, um zur Pflege zu zwingen.
3. Domain angeben. Daraus wird der Canonical-Wert vorbelegt, also die Adresse, unter der die Datei später erreichbar sein soll.
4. Optionale Felder ergänzen. Policy, Encryption und Preferred-Languages sind formal freiwillig, machen die Datei in der Praxis aber erst nützlich.
5. Prüfung lesen. Rechts erscheinen Fehler (rot – die Datei wäre ungültig) und Warnungen (gelb – gültig, aber verbesserungswürdig).
6. Datei herunterladen und hochladen. Die Datei muss über HTTPS unter /.well-known/security.txt erreichbar sein und mit dem Content-Type text/plain; charset=utf-8 ausgeliefert werden.

Expertenwissen: security.txt nach RFC 9116

Welches Problem der Standard löst

Jemand findet eine Sicherheitslücke in deiner Anwendung und möchte sie melden. Die typische Suche beginnt dann im Impressum, führt über ein allgemeines Kontaktformular in den Vertrieb und endet oft im Nichts – oder in einer Veröffentlichung ohne vorherige Meldung, weil kein Ansprechpartner auffindbar war. RFC 9116, veröffentlicht im April 2022 von der IETF als Standard der Kategorie „Informational“, beseitigt genau diese Reibung: Eine maschinenlesbare Textdatei an einem festgelegten Ort nennt den Meldeweg. Damit finden sowohl Menschen als auch automatisierte Scanner den richtigen Kanal, ohne raten zu müssen.

Der Standard ist bewusst minimal: kein JSON, kein Schema-Zwang, keine Registrierung bei einer zentralen Stelle. Eine Textdatei mit Feldname: Wert pro Zeile, Kommentare beginnen mit #. Genau diese Einfachheit ist der Grund für die schnelle Verbreitung.

Die Felder im Einzelnen

Die beiden Felder mit „Mehrfach: nein“ sind die häufigste Fehlerquelle. Kommt Expires oder Preferred-Languages zweimal vor, ist die gesamte Datei nach Standard ungültig – nicht nur die doppelte Zeile. Feldnamen sind dabei nicht groß-/kleinschreibungssensitiv; contact: ist so gültig wie Contact:.

Ablage, Auslieferung und Signatur

Der Speicherort ist nicht verhandelbar: /.well-known/security.txt, ausgeliefert über HTTPS. Der Pfad /.well-known/ stammt aus RFC 8615 und ist der reservierte Ort für maschinenlesbare Metadaten einer Domain – dieselbe Systematik nutzen ACME für Let's-Encrypt- Prüfungen oder change-password für Passwortmanager. Aus Kompatibilität mit der Zeit vor dem RFC darf die Datei zusätzlich unter /security.txt liegen; existieren beide, gilt die Fassung unter /.well-known/. Der Content-Type muss text/plain; charset=utf-8 sein – wird die Datei als text/html oder als Download ausgeliefert, scheitern Prüfwerkzeuge.

Optional lässt sich die Datei mit einer OpenPGP-Cleartext-Signatur versehen. Das ist sinnvoll, wenn Angreifer durch Manipulation der Datei Meldungen auf eigene Adressen umleiten könnten. Wer signiert, sollte zwingend Canonical setzen: Erst dadurch lässt sich prüfen, ob die Signatur für genau diesen Fundort gedacht war und die Datei nicht anderswohin kopiert wurde.

Drei Praxisfälle

Fall 1 – Agentur mit vielen Kundendomains. Eine Webagentur betreibt 80 Kundenauftritte. Sinnvoll ist eine zentrale Meldeadresse der Agentur in allen Dateien, kombiniert mit einer Policy-Seite, die die Zuständigkeit erklärt. Der Fallstrick: Canonical ist je Domain unterschiedlich und darf nicht aus einer Vorlage kopiert werden – sonst zeigen alle 80 Dateien auf dieselbe Adresse und werden als fremd erkannt.

Fall 2 – Behörde oder KRITIS-Betreiber. Hier zählt Nachvollziehbarkeit. Empfohlen sind eine funktionsbezogene Adresse statt einer Personenadresse (mailto:cert@… statt mailto:max.mustermann@…), eine Encryption-URI für verschlüsselte Zusendung und ein Expires von maximal einem Jahr, das in den regulären Prüfzyklus aufgenommen wird. Ein CSAF-Verweis lohnt sich, sobald eigene Sicherheitsmeldungen maschinenlesbar veröffentlicht werden.

Fall 3 – kleiner Shop oder Einzelprojekt. Auch ohne Sicherheitsteam ist die Datei sinnvoll: Zwei Zeilen mit Contact und Expires genügen, um überhaupt erreichbar zu sein. Wichtig ist hier vor allem, dass das Postfach tatsächlich gelesen wird – eine security.txt, die auf eine unbeachtete Adresse zeigt, ist schlechter als keine, weil sie Reaktionsbereitschaft suggeriert.

Typische Fehler

• Expires fehlt. Der häufigste Fehler überhaupt – viele Dateien stammen noch aus der Entwurfsphase, in der das Feld optional war. Ohne Expires ist die Datei heute ungültig.
• Abgelaufenes Expires. Einmal gesetzt und nie erneuert. Prüfwerkzeuge behandeln die Datei dann als nicht mehr gültig.
• Blanke E-Mail-Adresse. Contact: security@example.com ist keine URI. Korrekt ist Contact: mailto:security@example.com.
• Schlüsselblock in Encryption. Ein eingefügter BEGIN PGP PUBLIC KEY BLOCK ist ausdrücklich unzulässig – nur der Fundort gehört ins Feld.
• Falscher Ablageort. Nur /security.txt ohne /.well-known/ genügt nicht mehr.
• Falscher Content-Type. Manche Server liefern .txt-Dateien als Download aus oder erzwingen HTML-Fehlerseiten mit Status 200.
• Schreibweise „Acknowledgements“. Der RFC nutzt die Form ohne „e“ nach dem g: Acknowledgments.
• Datei nur über HTTP erreichbar. HTTPS ist Pflicht.

Häufige Fragen

Weitere nützliche Tools

• Subnetz- & CIDR-Rechner – Netzbereiche für Scope-Angaben
• EXIF-Betrachter & Entferner – Metadaten aus Screenshots eines Reports entfernen
• Alle Security-Tools – Übersicht des Segments
• Alle Entwickler-Tools – Netzwerk, Formate, Kodierung