Meldungen und IOC

security.txt-Generator

Läuft lokal

Das Tool selbst ist auf Englisch; auf dieser Seite wird es in Ihrer Sprache erklärt.

security.txt-Generator verwenden

Was es bewirkt

Erstellen Sie eine security.txt-Datei, damit Forschende und Personen, die Phishing im Namen Ihrer Marke melden, wissen, wie sie Sie erreichen. Speichern Sie das Ergebnis als /.well-known/security.txt.

Es läuft vollständig in Ihrem Browser: Es werden keine Ihrer Eingaben hochgeladen.

So verwenden Sie security.txt-Generator

  1. Kontakt eingeben. Geben Sie unter „Kontakt“ ein, wie Ihr Sicherheitsteam erreichbar ist, jeweils eine Angabe pro Zeile: mailto:security@example.com, eine https://-Adresse eines Meldeformulars oder eine Tel.-Nummer. Bei einer reinen E-Mail-Adresse wird „mailto:“ hinzugefügt.
  2. Ablaufdatum festlegen. Wählen Sie unter Expires ein Datum. Voreingestellt ist ein Jahr ab heute; RFC 9116 empfiehlt weniger als ein Jahr, wählen Sie daher ein früheres Datum.
  3. Optionale Felder hinzufügen. Füllen Sie Preferred-Languages (standardmäßig en), Canonical, Policy, Encryption, Acknowledgments und Hiring aus, sofern vorhanden. Leere Felder werden in der Datei weggelassen.
  4. Erzeugen und kopieren. Drücken Sie Generate, und lesen Sie das Ergebnis im Ausgabefeld. Prüfen Sie jede Adresse noch einmal, weil das Tool sie so übernimmt, wie sie eingegeben wurden, und drücken Sie dann Copy.
  5. Veröffentlichen und erneuern. Speichern Sie den Text als /.well-known/security.txt auf Ihrer Website mit HTTPS, signieren Sie ihn bei Bedarf mit gpg --clearsign, und notieren Sie sich einen Termin, um ihn vor dem Ablauf zu erneuern.

Beispiel

Minimale Datei

Eingabe
mailto:security@example.com
Ausgabe (aufgezeichnet am 2026-10-20)
Contact: mailto:security@example.com
Expires: 2027-10-20T23:59:59.000Z
Preferred-Languages: en

Erzeugt „Contact: mailto:security@example.com“, eine „Expires“-Zeile, die ein Jahr in der Zukunft um 23:59:59Z abläuft, sowie „Preferred-Languages: en“ – die beiden Pflichtfelder sowie einen Sprachhinweis –, mit dem Hinweis, dass RFC 9116 ein „Expires“-Datum empfiehlt, das weniger als ein Jahr in der Zukunft liegt.

Was dabei geprüft wird

SignalWas das bedeutet
Contact:Eine Zeile pro Kontakt, in der Reihenfolge, in der Sie sie eingegeben haben. Jeder Eintrag muss gemäß RFC 9116 eine „mailto:“, „https://“ oder „tel:“-URI sein; „http://“ und fehlerhafte Werte führen zu einer Fehlermeldung statt zur Anzeige einer Datei.
Expires:Das gewählte Datum um 23:59:59 UTC, mit Millisekunden geschrieben, zum Beispiel 2027-03-31T23:59:59.000Z. Leeren Sie das Datumsfeld, erzeugt Generate keine neue Datei mehr.
Preferred-Languages:Standardmäßig en. Verwenden Sie durch Kommas getrennte Sprachcodes wie en, de, oder leeren Sie das Feld, um die Zeile wegzulassen.
Canonical:Die vollständige https://-Adresse, unter der diese Datei liegt, damit eine Kopie, die anderswo ausgeliefert wird, erkannt werden kann.
Encryption:Ein Link zu Ihrem öffentlichen OpenPGP-Schlüssel, damit Meldende sensible Details verschlüsseln können.
Policy, Acknowledgments, HiringLinks zu Ihrer Offenlegungsrichtlinie, zu einer Seite, auf der Sie Meldenden danken, und zu Stellen im Sicherheitsbereich. Alles optional, und das Tool prüft nicht, ob die Links funktionieren.
Eine Funktionsadresse unter ContactVerwenden Sie eine Adresse oder ein Formular, das ein Team betreut, etwa security@ Ihrer Domain, nicht das Postfach einer einzelnen Person, damit Meldungen auch dann ankommen, wenn Personen den Job wechseln.
Error: Contact is requiredWird angezeigt, wenn das Feld „Kontakt“ leer ist. Bei einem Fehler wird die Ausgabe durch einen Hinweis ersetzt, dass erst dann etwas generiert wird, wenn die Felder korrigiert wurden.

Weitere Beispiele

Webformular mit Sprachen und Richtlinie

Eingabe
Contact https://example.org/report-security, Expires 2027-03-31, Preferred-Languages en, de, Canonical https://example.org/.well-known/security.txt, Policy https://example.org/security-policy
Ergebnis

Fünf Zeilen in dieser Reihenfolge: Contact: https://example.org/report-security, Expires: 2027-03-31T23:59:59.000Z, Preferred-Languages: en, de, Canonical: https://example.org/.well-known/security.txt, Policy: https://example.org/security-policy.

E-Mail-Kontakt mit Schlüssel, ohne Sprache

Eingabe
Contact mailto:abuse@example.net, Expires 2027-06-30, Preferred-Languages cleared, Encryption https://example.net/pgp-key.txt
Ergebnis

Drei Zeilen: Contact: mailto:abuse@example.net, Expires: 2027-06-30T23:59:59.000Z und Encryption: https://example.net/pgp-key.txt.

Contact leer gelassen

Eingabe
All fields filled except Contact
Ergebnis

Fehler: Das Feld „Kontakt“ muss ausgefüllt werden, und es wird angezeigt, dass nichts generiert wurde. Die anderen Felder behalten ihre Werte bei. Füllen Sie daher das Feld „Kontakt“ aus und klicken Sie erneut auf „Generieren“.

Häufig gestellte Fragen

Welche Felder sind Pflicht?

RFC 9116 schreibt mindestens ein „Contact“-Feld und genau ein „Expires“-Feld vor; die übrigen Felder sind optional. Jede „Contact“-Zeile muss eine „mailto:“, „https://“ oder „tel:“-URI sein (bei einer reinen E-Mail-Adresse wird „mailto:“ angehängt), „Expires“ muss ein zukünftiges Datum sein, und „Generate“ zeigt einen Fehler anstelle einer Datei an, solange eines dieser Felder fehlt oder ungültig ist.

Worauf sollte ich Expires setzen?

Als Standarddatum wird ein Jahr ab heute festgelegt, während RFC 9116 einen Zeitraum von weniger als einem Jahr empfiehlt. Wählen Sie daher ein früheres Datum, um dieser Empfehlung zu folgen; die Seite weist Sie darauf hin, wenn das Datum mehr als ein Jahr in der Zukunft liegt. Erneuern Sie die Datei vor diesem Datum, da laut RFC eine abgelaufene „security.txt“-Datei als veraltet behandelt werden sollte.

Wird etwas hochgeladen oder signiert?

Nein. Die Datei wird in Ihrem Browser zusammengestellt, und nichts wird irgendwohin gesendet. Sie ist nicht signiert; RFC 9116 empfiehlt eine OpenPGP-Cleartext-Signatur, die Sie vor der Veröffentlichung mit gpg --clearsign hinzufügen können.

Kann ich mehr als einen Kontakt angeben?

Ja. RFC 9116 erlaubt mehrere Kontaktzeilen, die in der Reihenfolge ihrer Priorität gelesen werden. Geben Sie im Feld „Kontakt“ jeweils einen Kontakt pro Zeile ein; Duplikate werden nur einmal geschrieben.

Wo genau gehört die Datei hin?

Unter https://your-domain/.well-known/security.txt, per HTTPS als einfacher Text ausgeliefert. Eine Kopie oder Weiterleitung unter /security.txt ist optional.

Gilt eine Datei auch für meine Subdomains?

Nein. Laut RFC 9116 gilt eine security.txt nur für den Host, von dem sie abgerufen wurde, nicht für dessen Subdomains oder übergeordnete Domain. Veröffentlichen Sie auf jedem Host, auf dem Menschen nachsehen könnten, eine Kopie, etwa auf www und shop.

Wie hilft security.txt gegen Phishing, das meine Marke kopiert?

Wer eine Lookalike-Website oder eine gefälschte E-Mail in Ihrem Namen findet, möchte Sie oft warnen. Eine funktionierende Contact-Zeile bringt diese Meldung zu Ihrem Sicherheitsteam statt in eine allgemeine Support-Warteschlange, sodass Sie schneller gegen die Lookalike-Domain vorgehen können.

Begriffserläuterungen

PhishDestroy-Forschung