security.txt prüfen
Geben Sie eine Website ein und sehen Sie, ob sie Sicherheitsforschern sagt, wo sie ein Problem melden können, und ob diese Datei am richtigen Ort liegt, korrekt aufgebaut und noch gültig ist. Gibt es keine, können Sie sie unten erstellen.
Eine security.txt schreiben
Füllen Sie aus, was zutrifft, und kopieren Sie das Ergebnis. Die Datei wird in dieser Seite zusammengesetzt: Nichts, was Sie hier eingeben, wird an uns gesendet.
Eine E-Mail-Adresse oder die https://-Adresse eines Formulars. Nehmen Sie ein gemeinsames Postfach, keine Person: Menschen gehen.
Eine Seite, die sagt, was getestet werden darf und was ein Melder von Ihnen erwarten kann.
Sprachcodes, durch Kommas getrennt.
Fügt eine Canonical-Zeile hinzu, die die Datei an ihre Adresse bindet.
Voreingestellt auf ein Jahr ab heute, die längste Frist, die der Standard empfiehlt.
- Speichern Sie den Text als Datei namens
security.txt, in UTF-8 kodiert. - Laden Sie sie in einen Ordner namens
.well-knownim Stammverzeichnis der Website hoch, sodass sie unterhttps://your-domain/.well-known/security.txtantwortet. - Führen Sie die Prüfung oben aus: Die Datei muss über HTTPS als
text/plainzurückkommen. - Tragen Sie das Ablaufdatum in einen Kalender ein. Eine abgelaufene Datei ist schlimmer als keine, weil sie verlassen wirkt.
Eine Eingangstür für schlechte Nachrichten
Früher oder später entdeckt jemand außerhalb Ihrer Organisation einen Fehler auf Ihrer Website: eine Seite, die Bestellungen anderer Kunden zeigt, ein vergessenes Admin-Panel, ein Passwort-Reset, der sich wiederverwenden lässt. Die meisten dieser Leute wollen es Ihnen sagen. Schwierig ist nur, jemanden zu finden, dem man es sagen kann. Das Kontaktformular landet beim Vertrieb, der Support-Chat will eine Bestellnummer, und unter info@ antwortet niemand.
Eine security.txt-Datei löst genau dieses eine Problem. Es sind ein paar Zeilen reiner Text an einer festen Adresse, /.well-known/security.txt, die sagen, wohin Meldungen gehen und bis wann diese Angaben gelten. Das Format wurde 2022 als RFC 9116 veröffentlicht. Scanner, Bug-Bounty-Plattformen und nationale Sicherheitsbehörden lesen die Datei automatisch, wenn sie etwas weiterzugeben haben.
Contact: mailto:security@example.com
Expires: 2027-01-31T00:00:00.000Z
Preferred-Languages: en, de
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policyWas diese Prüfung liest
Unser Server fragt https://your-host/.well-known/security.txt an und, wenn dort nichts kommt, die ältere Adresse /security.txt im Stammverzeichnis. Weiterleitungen werden verfolgt. Eine Antwort mit Status 200, die sich als HTML-Seite entpuppt, zählt als keine Datei, denn viele Websites beantworten jede unbekannte Adresse mit ihrer Startseite.
Gibt es eine Datei, bewerten wir sie nach drei Dingen.
| Teil | Was erfüllt sein muss |
|---|---|
| Wie sie ausgeliefert wird | An der Adresse /.well-known/, über HTTPS, mit Content-Type: text/plain. Eine Weiterleitung auf eine andere Domain wird angemerkt. |
Contact | Mindestens einer, jeweils als URI: mailto:, https:// oder tel:. Eine nackte E-Mail-Adresse ohne mailto: ist ein Fehler. |
Expires | Genau einer, als vollständiger Zeitstempel wie 2027-01-31T00:00:00.000Z, in der Zukunft. Abgelaufen ist ein Fehler; weniger als 30 Tage Restlaufzeit oder mehr als ein Jahr im Voraus ist eine Warnung. |
| Optionale Felder | Encryption, Acknowledgments, Policy, Hiring und CSAF müssen https://-Adressen sein. Preferred-Languages kommt einmal vor und enthält Sprachcodes. Canonical muss die Adresse enthalten, von der die Datei gelesen wurde. |
Feldnamen außerhalb des Standards werden ohne Abzug aufgelistet, denn Erweiterungen sind erlaubt. Die Prüfung sagt auch, ob der Text in eine OpenPGP-Klartextsignatur eingebettet ist. Diese Signatur überprüft sie nicht.
Die häufigsten Fehler
- Ein abgelaufenes Datum
- Jemand hat die Datei einmal geschrieben und dann vergessen. Laut RFC 9116 soll eine abgelaufene Datei nicht verwendet werden, also muss ein Melder wieder raten. Die Erneuerung dauert zwei Minuten: Kontakte bestätigen, Datum verschieben, veröffentlichen.
- Gar kein
Expires - Dateien von vor 2022 folgten einem Entwurf, in dem das Feld optional war. Heute ist es Pflicht.
Contact: security@example.com- Der Wert muss eine URI sein. Schreiben Sie
mailto:security@example.com. - Die Datei nur im Stammverzeichnis
/security.txtist ein Notbehelf. Legen Sie die Datei in/.well-known/ab und leiten Sie die alte Adresse dorthin weiter.- Ein von einer anderen Website kopiertes
Canonical - Ist das Feld vorhanden und nennt nicht die Adresse, von der die Datei ausgeliefert wird, widerspricht sich die Datei selbst.
Eine Datei veröffentlichen, die Sie aktuell halten können
Legen Sie zuerst fest, wer das Postfach liest. Eine gemeinsame Adresse wie security@, die zwei Personen erreicht, ist besser als eine einzelne namentlich genannte Person. Nutzen Sie dann den Generator auf dieser Seite. Er ergänzt mailto:, wo nötig, formatiert das Datum und setzt es vorab auf ein Jahr in der Zukunft.
Laden Sie das Ergebnis in einen Ordner namens .well-known im Web-Stammverzeichnis hoch. Die meisten Server liefern .txt-Dateien ohne weiteres Zutun als text/plain aus. Versteckt Ihrer Ordner, die mit einem Punkt beginnen, fügen Sie eine Ausnahme hinzu. In nginx:
location = /.well-known/security.txt {
default_type text/plain;
charset utf-8;
}Signieren ist optional. Mit GnuPG erzeugt gpg --clearsign security.txt eine signierte Fassung, die Sie stattdessen veröffentlichen. Fügen Sie vor dem Signieren eine Canonical-Zeile ein, damit die Signatur auch die Adresse abdeckt.
Diese Seite liest einen Host, einmal. Sie kann nicht feststellen, ob unter der Kontaktadresse jemand antwortet, ob die verlinkte Richtlinie existiert oder ob die Signatur echt ist. Eine fehlende Datei ist keine Sicherheitslücke und senkt hier keine Bewertung.
Häufige Fragen
Ist eine fehlende security.txt eine Sicherheitslücke?
Nein. Die Datei ist eine Gefälligkeit, die das Melden erleichtert, und schützt für sich genommen nichts. Manche automatischen Scanner führen ihr Fehlen als Befund mit geringem Schweregrad auf. Verstehen Sie das als Vorschlag.
Wo genau gehört die security.txt hin?
Nach https://your-domain/.well-known/security.txt, über HTTPS als reiner Text ausgeliefert. Jeder Host ist getrennt, eine Datei auf example.com gilt also nicht für app.example.com.
Lockt eine veröffentlichte Kontaktadresse Spam oder falsche Fehlermeldungen an?
Rechnen Sie mit einigen automatisierten, wenig wertvollen Meldungen, oft mit der Bitte um eine Belohnung. Eine kurze Richtlinienseite, die sagt, was Sie als relevant betrachten und ob Sie Prämien zahlen, filtert die meisten davon heraus. Es hilft auch, Contact auf ein Webformular statt auf ein Postfach zeigen zu lassen.
Wie weit in der Zukunft sollte das Expires-Datum liegen?
Weniger als ein Jahr, wie der RFC empfiehlt. Das Datum ist ein Versprechen, dass die Kontakte bei der letzten Überprüfung der Datei stimmten, deshalb soll es kurz sein. Stellen Sie sich eine Erinnerung einen Monat vor Ablauf.
Muss ich die Datei mit PGP signieren?
Nein. Eine Signatur hilft einem Leser zu bestätigen, dass die Datei auf einem kompromittierten Server nicht verändert wurde, und sie funktioniert nur, wenn Ihr öffentlicher Schlüssel anderswo erhältlich ist. Viele gültige Dateien sind unsigniert.
Was ist der Unterschied zwischen security.txt und robots.txt?
Beides sind reine Textdateien an einer bekannten Adresse, die von Software gelesen werden. robots.txt sagt Crawlern, welche Seiten sie in Ruhe lassen sollen. security.txt sagt Menschen, die ein Sicherheitsproblem gefunden haben, wie sie Sie erreichen. Keine der beiden erzwingt irgendetwas.