security.txt-Generator — eine RFC-9116-Datei erstellen und prüfen

Erstelle eine gültige security.txt (RFC 9116) mit Feldern für Kontakt, Ablauf, Verschlüsselung und Richtlinie, prüfe eine bestehende und lade sie für /.well-known/ herunter.

Contact (erforderlich, einer pro Zeile)

E-Mail-Adressen, https://-Meldeformulare oder Telefonnummern. Bei reinen E-Mail-Adressen wird mailto: ergänzt. Nenne den bevorzugten Kontakt zuerst.

Expires (erforderlich)

RFC-3339-Datum mit Uhrzeit, weniger als ein Jahr in der Zukunft. Trag dir eine Erinnerung ein, um sie vor Ablauf zu erneuern.

Encryption (optional)

URL deines öffentlichen PGP-Schlüssels (https://, dns: oder openpgp4fpr:), nicht der Schlüssel selbst.

Preferred-Languages (optional)

Kommagetrennte Sprach-Tags, z. B. en, fr, pt-BR.

Canonical (empfohlen)

Die https://-URL(s), unter der diese Datei liegt. Praktisch erforderlich, wenn du sie signierst.

Policy (optional)

Deine Richtlinie zur Offenlegung von Schwachstellen: Umfang, Safe Harbor, wie du reagierst.

Acknowledgments (optional)

Eine Seite, die Forschern dankt, die Probleme gemeldet haben (Hall of Fame).

Hiring (optional)

Stellenangebote im Sicherheitsbereich.

CSAF (optional)

Für Hersteller, die maschinenlesbare Advisories veröffentlichen: URL der provider-metadata.json.

Kommentar (optional, als #-Zeilen geschrieben)

Gültig: Alle Pflichtfelder sind vorhanden, und jeder Wert entspricht RFC 9116.

security.txt

…

Wohin damit

Liefere sie unter https://yourdomain.com/.well-known/security.txt über HTTPS als text/plain; charset=utf-8 aus. Optional leitest du /security.txt dorthin weiter.
Next.js, Astro, Vite und die meisten statischen Hoster: speichere sie als public/.well-known/security.txt. WordPress, Apache oder nginx: lege im Web-Root einen Ordner .well-known an.
Jede Subdomain mit eigener Website sollte eine eigene Datei haben (oder Besucher per Kommentar auf die Hauptdatei verweisen).
Optional: Signiere sie mit gpg --clearsign security.txt und veröffentliche die signierte Ausgabe; nimm Canonical auf, damit die Signatur auch den Speicherort abdeckt.

Läuft komplett in deinem Browser. Nichts, was du eingibst, wird an uns gesendet oder gespeichert. Alle kostenlosen Tools ansehen.

Ein Problem gefunden oder etwas, das besser sein könnte? Wir lesen jede Nachricht und beheben Fehler schnell.

Dieser kostenlose security.txt-Generator erstellt die kleine, als RFC 9116 standardisierte Textdatei, die Sicherheitsforschern sagt, wie sie eine Schwachstelle auf deiner Website melden können. Gib einen Kontakt und ein Ablaufdatum ein und optional deinen Verschlüsselungsschlüssel, deine Offenlegungsrichtlinie, eine Danksagungsseite, bevorzugte Sprachen und die kanonische URL; die Datei wird beim Tippen anhand des RFC geprüft und als security.txt heruntergeladen, bereit zum Hochladen nach /.well-known/security.txt.

Ohne sie muss jemand, der eine Lücke auf deiner Website findet, raten, wohin er sie schicken soll, und Meldungen landen im Support-Postfach, in sozialen Medien oder nirgends. Die Datei ist in fünf Minuten erstellt und wird von vielen Sicherheitsscannern und Bug-Bounty-Forschern abgefragt. Der zweite Tab prüft eine Datei, die du bereits veröffentlichst. Das Tool signiert die Datei nicht (dafür nutzt du gpg) und ruft deine Live-Datei nicht ab, weil die Seite keine Netzwerkanfragen stellt.

So funktioniert’s

Gib mindestens einen Contact ein: eine Sicherheits-E-Mail-Adresse, die URL eines Meldeformulars oder eine Telefonnummer. Setz den bevorzugten Kontakt an die erste Stelle.
Lege Expires über einen der Buttons fest (sechs Monate sind ein guter Standard) oder tippe ein Datum mit Uhrzeit nach RFC 3339.
Füge die optionalen Felder hinzu, die du hast: die URL deines PGP-Schlüssels, deine Offenlegungsrichtlinie, eine Dankesseite, Sprachen, die du liest, und die kanonische URL der Datei.
Behebe alles, was rot markiert ist; gelbe Punkte sind Empfehlungen.
Lade security.txt herunter und veröffentliche sie unter https://yourdomain.com/.well-known/security.txt, ausgeliefert als text/plain. Stell dir eine Erinnerung, um Expires zu aktualisieren.

Häufige Fragen

Was ist security.txt?

Eine Klartextdatei unter /.well-known/security.txt, die angibt, wie man Sicherheitslücken in einer Website oder einem Produkt meldet. Sie wurde im April 2022 von der IETF als RFC 9116 veröffentlicht. Nur zwei Felder sind Pflicht, Contact und Expires; die übrigen (Encryption, Acknowledgments, Preferred-Languages, Canonical, Policy, Hiring) sind optional.

Wohin kommt die security.txt-Datei?

Unter https://yourdomain.com/.well-known/security.txt, ausgeliefert über HTTPS mit dem Content-Type text/plain; charset=utf-8. Den alten Speicherort /security.txt im Stammverzeichnis lesen manche Tools noch; dort kannst du eine Kopie ausliefern oder weiterleiten. In Next.js, Astro, Vite und bei den meisten statischen Hostern legst du die Datei in public/.well-known/. Jeder Hostname, der eine eigene Website ist, sollte eine eigene Datei haben.

Warum ist das Feld Expires Pflicht?

Damit veralteten Kontaktdaten nicht ewig vertraut wird. RFC 9116 macht Expires verpflichtend und empfiehlt ein Datum weniger als ein Jahr in der Zukunft; ist es überschritten, sollten Forscher und Scanner die Datei als veraltet betrachten. Sechs Monate mit einer Kalendererinnerung zur Erneuerung sind ein praktischer Rhythmus, und der Generator warnt, wenn das Datum überschritten oder mehr als ein Jahr entfernt ist.

Sollte ich security.txt signieren?

Signieren ist optional, aber empfohlen. Führe gpg --clearsign security.txt mit einem Schlüssel aus, dessen öffentlichen Teil du veröffentlichst (das Feld Encryption kann darauf verweisen), und lade stattdessen die signierte Ausgabe hoch. Wenn du signierst, füge ein Feld Canonical hinzu, damit eine signierte Kopie von einer URL nicht als gültig für eine andere ausgegeben werden kann.

Kann ich einen Link zu einer Bug-Bounty-Plattform als Kontakt angeben?

Ja. Contact akzeptiert jede https://-URI, eine Programmseite bei HackerOne, Bugcrowd, Intigriti oder YesWeHack oder dein eigenes Meldeformular ist also gültig. Viele Organisationen geben sowohl einen Plattform-Link als auch eine E-Mail-Adresse an, in der Reihenfolge ihrer Präferenz.

Felder nach RFC 9116 auf einen Blick

• Contact (Pflicht, wiederholbar): mailto:-, https:- oder tel:-URI. Die Reihenfolge gibt die Präferenz an.

• Expires (Pflicht, genau einmal): Datum mit Uhrzeit nach RFC 3339, etwa 2027-04-30T23:59:59Z; empfohlen weniger als ein Jahr in der Zukunft.

• Encryption (wiederholbar): wo dein öffentlicher Schlüssel zu finden ist, als https://, dns: (OPENPGPKEY-Eintrag) oder openpgp4fpr: (Fingerabdruck). Füge niemals den Schlüssel selbst ein.

• Acknowledgments (wiederholbar): eine Seite, auf der du Meldenden dankst.

• Preferred-Languages (einmal): kommagetrennte Sprach-Tags, z. B. en, fr.

• Canonical (wiederholbar): die URL(s), unter denen diese Datei liegen soll.

• Policy (wiederholbar): deine Richtlinie zur Offenlegung von Schwachstellen.

• Hiring (wiederholbar): Stellen im Sicherheitsbereich.

• CSAF (wiederholbar, von OASIS registriert): die provider-metadata.json eines CSAF-Advisory-Feeds.

Web-URIs müssen https:// verwenden. Zeilen, die mit # beginnen, sind Kommentare.

Was in deine Offenlegungsrichtlinie gehört

Über den Policy-Link erfahren Forscher, ob es sicher ist, etwas zu melden. Nenne den Geltungsbereich (welche Domains und Apps), was ausgeschlossen ist (Denial of Service, Social Engineering, Ausgaben automatischer Scanner), wie schnell du Meldungen bestätigst und behebst, ob du Belohnungen anbietest, und eine Safe-Harbor-Erklärung, dass du gegen Forschung in gutem Glauben, die der Richtlinie folgt, nicht rechtlich vorgehst. Eine kurze, klare Seite bringt mehr brauchbare Meldungen als eine lange juristische.

security.txt und robots.txt

Sie liegen nebeneinander, erfüllen aber unterschiedliche Aufgaben: robots.txt bittet Crawler, bestimmte Inhalte nicht abzurufen, security.txt sagt Menschen, wie sie deinen Sicherheitskontakt erreichen. Führe security.txt oder /.well-known/ nicht unter Disallow auf; Forscher und Scanner müssen sie lesen, und eine Sperre in robots.txt versteckt sie ohnehin nicht.