Kostenloses ToolSchwachstellenbehandlung

security.txt-Generator

Gültige security.txt in einer Minute: Kontakt, Ablaufdatum und optionale Felder nach RFC 9116, mit Prüfung. Kopieren und unter /.well-known/ veröffentlichen.

Aktualisiert 7. Oktober 2026Diese Seite als Markdown

Kurz gesagt

Dieser Generator baut eine security.txt nach RFC 9116, dem Standard, der Sicherheitsforschern sagt, wie sie dir eine Schwachstelle melden können. Du gibst mindestens einen Kontakt und ein Ablaufdatum an; die optionalen Felder Encryption, Policy, Acknowledgments, Hiring, Canonical und Preferred-Languages werden auf das richtige Format geprüft. Die Datei gehört unter /.well-known/security.txt auf deinen Webserver.

Contact (Pflicht)

Einer pro Zeile oder kommagetrennt: mailto:, tel: oder eine https://-URL. Der erste wird bevorzugt.

Expires (Pflicht)

Muss in der Zukunft liegen. RFC 9116 empfiehlt weniger als ein Jahr.

Optionale Felder

Encryption

https://-URL deines PGP-Schlüssels.

Policy

Acknowledgments

Hiring

Canonical

Die https://-URL, unter der diese Datei liegen wird.

Preferred-Languages

Sprachcodes, kommagetrennt.

Deine security.txt

Contact: mailto:security@example.com
Expires: 2027-10-08T00:00:00Z
Preferred-Languages: en, de

Veröffentliche sie über HTTPS unter /.well-known/security.txt

Wenn du einen Encryption-Schlüssel veröffentlichst, signiere die Datei nach Möglichkeit mit PGP (Klartextsignatur), wie RFC 9116 es beschreibt.

So funktioniert es

Das Tool schreibt die Felder genau so, wie RFC 9116 sie definiert: eine Contact-Zeile pro Adresse, eine Expires-Zeile mit ISO-8601-Zeitstempel und die optionalen Felder nur, wenn du sie ausfüllst. Kontakte, die wie E-Mail-Adressen aussehen, bekommen das Präfix mailto:. Jedes URL-Feld muss HTTPS nutzen und Expires in der Zukunft liegen, sonst zeigt das Tool den Fehler und sperrt Kopieren und Download.

So liest du das Ergebnis

Die Datei nützt nur, wenn Forscher sie finden. Veröffentliche sie unter https://deine-domain/.well-known/security.txt (der alte Ort /security.txt darf dorthin weiterleiten). Die Kontaktadresse sollte Leute erreichen, die handeln können, kein allgemeines Postfach. Sag auf deiner Policy-Seite, was Meldende erwarten können: Reaktionszeit, ob du Prämien zahlst und dass gutgläubige Forschung nicht mit rechtlichen Drohungen beantwortet wird.

Grenzen

Der Generator prüft das Format, nicht deinen Prozess. Eine security.txt, deren Postfach niemand liest, ist schlimmer als keine, weil sie eine Antwort verspricht. Für Hersteller unter dem Cyber Resilience Act ist die Datei ein Baustein der Policy zur koordinierten Offenlegung, die die Verordnung verlangt; die Policy selbst, der Behandlungsprozess und die Meldepflichten gegenüber ENISA und dem nationalen CSIRT sind eigene Arbeit.

FAQ

Häufig gestellte Fragen

Ist eine security.txt gesetzlich vorgeschrieben?

Nicht namentlich. Der Cyber Resilience Act verlangt von Herstellern von Produkten mit digitalen Elementen eine Policy zur koordinierten Offenlegung von Schwachstellen und eine Kontaktadresse für Meldungen (Anhang I, Teil II). Eine security.txt ist der einfachste Weg, diese Adresse dort zu veröffentlichen, wo Forscher zuerst nachsehen.

Warum braucht die Datei ein Ablaufdatum?

RFC 9116 macht Expires verpflichtend, damit veraltete Kontakte nicht jahrelang stehen bleiben. Forscher behandeln eine abgelaufene Datei als unzuverlässig. Wähle ein Datum innerhalb eines Jahres und trag dir eine Erinnerung ein.

Soll ich die Datei signieren?

Wenn du einen Encryption-Schlüssel veröffentlichst, beweist eine PGP-Signatur, dass die Datei nicht manipuliert wurde. Die Signatur ist optional. Die meisten Organisationen starten ohne Signatur und ergänzen sie, sobald ein Schlüsselmanagement-Prozess steht.

Quellen

Passende Seiten

← Kostenlose Tools