Abuse-Meldungen für Registrare, Hosting-Provider und CDNs erstellen, als E-Mail und als JSON.
security.txt-Generator
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
- 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.
- 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.
- 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.
- 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.
- 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
mailto:security@example.comContact: mailto:security@example.com
Expires: 2027-10-20T23:59:59.000Z
Preferred-Languages: enErzeugt „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
| Signal | Was 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, Hiring | Links 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 Contact | Verwenden 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 required | Wird 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
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-policyFü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
Contact mailto:abuse@example.net, Expires 2027-06-30, Preferred-Languages cleared, Encryption https://example.net/pgp-key.txtDrei Zeilen: Contact: mailto:abuse@example.net, Expires: 2027-06-30T23:59:59.000Z und Encryption: https://example.net/pgp-key.txt.
Contact leer gelassen
All fields filled except ContactFehler: 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.