security-txt.de

AnleitungStand Lesezeit 9 Min.

security.txt einrichten: Schritt für Schritt

Eine security.txt sagt allen, die eine Sicherheitslücke auf Ihrer Webseite oder in Ihren Produkten gefunden haben, wohin sie sie melden sollen. Die Datei ist schnell geschrieben. Diese Anleitung zeigt, was hineingehört, wie Sie sie signieren, auf dem Server richtig ausliefern und aktuell halten.

Was ist die security.txt?

Die security.txt ist eine kleine Textdatei, die unter https://ihre-domain/.well-known/security.txt liegt. Festgelegt ist sie in RFC 9116, einem Dokument der IETF vom April 2022. Jede Zeile ist ein Feld nach dem Muster Feldname: Wert, Kommentare beginnen mit #. Sicherheitsforschende, Prüfdienste und Meldestellen wie CERTs werten sie automatisiert aus.

Zwei Dinge regelt RFC 9116 ausdrücklich: Die Datei muss über HTTPS als text/plain mit charset=utf-8 ausgeliefert werden (RFC 9116 Abschnitt 3), und sie gilt nur für genau die Domain, unter der sie abgerufen wird, nicht für Subdomains oder die übergeordnete Domain (Abschnitt 3.1). Wer unter firma.de und www.firma.de erreichbar ist, braucht die Datei also unter beiden Adressen.

Die Felder im Überblick

RFC 9116 verlangt nur zwei Felder. Die Technische Richtlinie TR-03183-3 des BSI macht weitere zur Pflicht. Neuere Felder wie CSAF und Bug-Bounty stehen im Register der IANA.

FeldRFC 9116BSI TR-03183-3Inhalt
ContactPflicht, mehrfach erlaubt, in der Reihenfolge der VorliebePflicht: zuerst PSIRT-Postfach, dann CSIRT-Postfach, dann Meldeseite (4.2.3)mailto:, https:// oder tel:
ExpiresPflicht, genau einmal, empfohlen weniger als ein Jahr vorausPflicht, T und Z groß; soll höchstens ein Jahr voraus liegen (4.2.9)Datum nach RFC 3339
Canonicaloptional, empfohlen bei SignaturPflicht, ohne Weiterleitung erreichbar (4.2.2)Adresse der Datei selbst
EncryptionoptionalPflicht für jede Mailadresse aus Contact, direkt als .asc (4.2.4, 4.3.2)Adresse des OpenPGP-Schlüssels
Preferred-Languagesoptional, einmalPflicht, mindestens en (4.2.6)Sprachkürzel, mit Komma getrennt
PolicyoptionalPflicht (4.2.7)Adresse der CVD-Richtlinie
AcknowledgmentsoptionalSoll (4.2.5)Seite mit Danksagungen (Hall of Fame)
CSAFnicht im RFC, IANA-Register seit 2023Soll (4.2.8)Adresse der provider-metadata.json
Bug-Bountynicht im RFC, IANA-Register seit März 2026nicht geregeltTrue oder False
Hiringoptionalnicht geregeltStellenangebote im Sicherheitsbereich

Dazu kommt die Signatur: RFC 9116 empfiehlt eine OpenPGP-Signatur (Abschnitt 2.3), die TR verlangt sie (4.2.10). Fertige Dateien für beide Stufen finden Sie bei den Beispielen.

RFC 9116 oder BSI TR-03183-3?

RFC 9116 ist die weltweit genutzte Spezifikation der IETF und reicht für die meisten Webseiten. Die TR-03183-3 "Vulnerability Reports and Notifications" (Version 1.0.0 vom 20. August 2025, nur auf Englisch veröffentlicht) baut darauf auf und beschreibt, wie Hersteller Schwachstellenmeldungen annehmen: zwei getrennte Funktionspostfächer, Schlüssel, Meldeseite mit Formular, Richtlinie und Signatur.

Die TR ist freiwillig. Für Hersteller von Produkten mit digitalen Elementen ist sie trotzdem der naheliegende Maßstab: Der Cyber Resilience Act (CRA, Verordnung (EU) 2024/2847) verlangt ab dem 11. Dezember 2027 eine Kontaktadresse für Schwachstellenmeldungen (Anhang I Teil II Nummer 6), legt aber kein Format fest, und mit der TR beschreibt das BSI ein konkretes. Was das für Hersteller im Einzelnen heißt, erklärt der Leitfaden security.txt nach dem CRA. Für eine einfache Unternehmensseite ohne eigene Produkte genügt RFC 9116. Zum Einstieg empfiehlt das BSI die security.txt auch in seiner Cyber-Sicherheitsempfehlung BSI-CS 149.

Schritt 1: Datei erzeugen

Am schnellsten geht es mit dem Generator: Domain eintragen, Maßstab wählen, fehlende Adressen ergänzen. Er schreibt die Felder in der Reihenfolge und mit den Kommentaren der TR, setzt ein gültiges Ablaufdatum und lässt Sie die Datei erst kopieren, wenn sie fehlerfrei ist. Von Hand geht es auch; eine Datei nach RFC 9116 kann so kurz sein:

Contact: mailto:security@beispiel.de
Expires: 2027-10-01T00:00:00.000Z
Preferred-Languages: de, en
Canonical: https://www.beispiel.de/.well-known/security.txt

Wichtig für die Werte: nur ASCII-Zeichen außerhalb von Kommentaren (TR 4.2.1 c). Umlaut-Domains gehören in der Punycode-Schreibweise in die Datei, also xn--mller-kva.de statt müller.de.

Schritt 2: Schlüssel und Signatur

Die Signatur belegt, dass die Datei von Ihnen stammt und nicht von jemandem, der Meldungen umleiten will, sofern Prüfende Ihren Schlüssel kennen, etwa über den Fingerabdruck auf Ihrer Meldeseite. Sie brauchen dazu GnuPG. Die TR empfiehlt einen eigenen Schlüssel nur zum Signieren (4.2.10 b); er darf höchstens fünf Jahre gelten (4.2.10 e). Das Verfahren muss der BSI TR-03116-4 oder dem europäischen ECCG-Katalog entsprechen (4.2.10 d). Beide erfüllen elliptische Kurven wie NIST P-256 (nistp256) oder brainpoolP256r1; RSA ab 3000 Bit lässt nur der ECCG-Katalog zu. Ed25519, die Voreinstellung neuerer GnuPG-Versionen, steht in keinem der beiden. So legen Sie den Schlüssel mit NIST P-256 und zwei Jahren Laufzeit an:

gpg --quick-generate-key "Beispiel GmbH security.txt <security@beispiel.de>" nistp256 sign 2y
gpg --fingerprint security@beispiel.de
gpg --armor --export security@beispiel.de > security-txt-signatur.asc

Signiert wird mit einer Klartext-Signatur. Die Datei bleibt lesbar, die Signatur steht als Block darum:

gpg --clearsign --digest-algo SHA512 --local-user security@beispiel.de --output security.txt.signiert security.txt
mv security.txt.signiert security.txt

Den öffentlichen Schlüssel security-txt-signatur.asc legen Sie auf Ihre Webseite und nennen Adresse und Fingerabdruck auf der Meldeseite (TR 4.5.3 c und d). Nach der TR braucht außerdem jedes Funktionspostfach einen eigenen Schlüssel zum Verschlüsseln (4.3.1 j), dessen .asc-Datei im Feld Encryption steht:

gpg --quick-generate-key "Beispiel GmbH PSIRT <psirt@beispiel.de>" nistp256 sign 2y
gpg --quick-add-key <Fingerabdruck> nistp256 encr 2y
gpg --armor --export psirt@beispiel.de > psirt.asc

Der zweite Befehl ergänzt den Unterschlüssel zum Verschlüsseln; den Fingerabdruck zeigt der erste Befehl an. Für csirt@ genauso. Die Fingerabdrücke dieser Schlüssel gehören ebenfalls auf die Meldeseite (4.3.2 b).

Nach jeder Änderung an der Datei neu signieren: Schon ein einziges geändertes Zeichen macht die Signatur ungültig. Zeilenenden (LF oder CRLF) und Leerzeichen am Zeilenende verträgt die Klartext-Signatur, eine Umwandlung des Zeichensatzes oder ein vorangestelltes BOM nicht. Laden Sie die Datei deshalb unverändert (binär) hoch.

Schritt 3: Auf dem Server ausliefern

Die Datei gehört in den Ordner .well-known im Wurzelverzeichnis Ihrer Webseite. Der Ordnername beginnt mit einem Punkt; manche FTP-Programme blenden solche Ordner aus, und manche Serverkonfigurationen sperren sie. Prüfen Sie nach dem Hochladen, ob der Abruf Status 200 und den richtigen Typ liefert.

Apache

In der .htaccess im Wurzelverzeichnis oder in der Serverkonfiguration:

<Files "security.txt">
  ForceType "text/plain; charset=utf-8"
</Files>
<FilesMatch "\.asc$">
  ForceType application/pgp-keys
</FilesMatch>

nginx

Viele Vorlagen sperren alle Pfade, die mit einem Punkt beginnen. Erlauben Sie .well-known ausdrücklich und setzen Sie den Zeichensatz:

location ^~ /.well-known/ {
    allow all;
}
location = /.well-known/security.txt {
    charset utf-8;
}

WordPress und andere CMS

Legen Sie die Datei per FTP oder Dateimanager direkt in /.well-known/ neben die Ordner von WordPress. Eine echte Datei liefert der Webserver aus, bevor WordPress die Anfrage sieht. Prüfen Sie danach, ob nicht doch eine Fehlerseite des CMS mit Status 200 zurückkommt; das ist ein häufiger Fehler.

Cloudflare und andere Bot-Schutzdienste

Die TR verlangt, dass Prüfdienste die Datei automatisch abrufen können (4.2.11). Ein Bot-Schutz, der automatische Abrufe mit einer Prüfseite beantwortet, verhindert genau das. Bei Cloudflare lässt sich der einfache Bot Fight Mode nicht für einzelne Pfade abschalten; Ausnahmen für /.well-known/ sind erst mit Super Bot Fight Mode ab dem Pro-Tarif möglich. Ob Ihr Schutz zuschlägt, zeigt der Check.

Alte Adresse /security.txt

Liegt die Datei bisher nur unter /security.txt, verschieben Sie sie. Die alte Adresse darf auf die neue weiterleiten (RFC 9116 Abschnitt 3). Liegt die Datei an beiden Stellen, gilt die unter /.well-known/.

Schritt 4: Prüfen

Der Check ruft die Datei ab und prüft Aufbau, Ablaufdatum, Canonical, Verweise, Maildomains, Schlüssel und die Signatur, wahlweise nach RFC 9116 oder nach der TR. Von Hand geht es so:

curl -sI https://www.beispiel.de/.well-known/security.txt
curl -s https://www.beispiel.de/.well-known/security.txt | gpg --verify

Der erste Befehl muss HTTP/2 200 (oder 1.1) und content-type: text/plain; charset=utf-8 zeigen. Der zweite meldet "Good signature", wenn der öffentliche Schlüssel in Ihrem Schlüsselbund ist. Schicken Sie außerdem einmal selbst eine Mail an jede Adresse aus der Datei und sehen Sie nach, ob sie ankommt und gelesen wird.

Schritt 5: Pflegen

Eine security.txt hat ein Ablaufdatum, damit veraltete Angaben nicht ewig gelten. Danach gilt sie als veraltet, Prüfdienste werten das als Fehler. Drei Termine gehören deshalb in den Kalender:

  • Vor dem Ablaufdatum: Inhalt prüfen, neues Datum höchstens ein Jahr voraus setzen, neu signieren, hochladen.
  • Vierteljährlich: Die TR verlangt, die Angaben mindestens jedes Quartal zu prüfen und zu korrigieren (4.2.9 c).
  • Vor dem Ablauf der Schlüssel: Gültigkeit verlängern mit gpg --quick-set-expire <Fingerabdruck> 2y und für die Unterschlüssel zusätzlich gpg --quick-set-expire <Fingerabdruck> 2y '*', danach die .asc-Dateien neu exportieren. Der Fingerabdruck bleibt gleich.

Typische Fehler

Eine Auswertung der eine Million meistbesuchten Domains durch uriports (24. Januar 2025) zeigt, wie selten die Datei stimmt: Nur 1,25 Prozent hatten eine security.txt, davon entsprachen 44 Prozent dem RFC. Bei 45 Prozent fehlte Expires, bei 13 Prozent war es abgelaufen.

  • Falscher Ort: nur unter /security.txt statt unter /.well-known/security.txt.
  • Webseite statt Datei: Das CMS fängt den Pfad ab und liefert eine Fehlerseite mit Status 200.
  • Abgelaufenes Expires oder ein Datum mehr als ein Jahr voraus; nach der TR außerdem ein kleines t oder z im Datum.
  • Canonical zeigt woandershin, etwa auf firma.de, während die Datei unter www.firma.de liegt (laut uriports in 26 Prozent der Fälle).
  • Acknowledgements statt Acknowledgments: Das Feld schreibt sich amerikanisch; die britische Schreibweise fand uriports noch in 10 Prozent der Dateien.
  • E-Mail ohne mailto: im Feld Contact.
  • Encryption zeigt auf eine Seite statt direkt auf die .asc-Datei (nach der TR unzulässig, 4.3.2 d).
  • Signatur kaputt, weil die Datei nach dem Signieren bearbeitet oder beim Hochladen umgeschrieben wurde.
  • Niemand liest das Postfach. Der folgenreichste Fehler, den kein Prüfprogramm findet. Oft, weil es im Spam nach der security.txt untergeht.
Und wer liest die Meldungen? Hersteller unter dem CRA müssen gemeldete Schwachstellen bewerten und aktiv ausgenutzte binnen 24 Stunden über die Meldeplattform der ENISA melden. Das CRA Response Center liest das Security-Postfach mit, trennt echte Meldungen von Spam und bereitet die Meldung vor. So sortiert das CRA Response Center

Häufige Fragen

Ist die security.txt Pflicht?

Ein Gesetz schreibt die Datei nicht vor. Der Cyber Resilience Act (CRA) verlangt von Herstellern ab dem 11. Dezember 2027 eine Kontaktadresse für Schwachstellenmeldungen, aber kein Format. Die BSI TR-03183-3 verlangt die security.txt, ist aber freiwillig. Für alle anderen ist sie eine Empfehlung, unter anderem des BSI.

Bekomme ich durch die security.txt mehr Spam?

Meist ja, vor allem Beg-Bounty-Mails, die einen Allerweltsbefund melden und nach einer Prämie fragen. Bug-Bounty: False, eine klare Richtlinie, eine eigene Adresse und Filter, die sortieren statt löschen, halten es beherrschbar. Wie das geht, steht unter Spam nach der security.txt.

Welche Felder sind zwingend?

Nach RFC 9116 nur Contact und Expires. Nach der TR zusätzlich Canonical, Encryption, Preferred-Languages mit mindestens Englisch, Policy und die Signatur.

Wie lange darf das Ablaufdatum in der Zukunft liegen?

RFC 9116 empfiehlt weniger als ein Jahr, nach der TR soll es höchstens ein Jahr sein. Der Generator schlägt ein Jahr minus einen Tag vor.

Reicht security@ als Adresse?

Für RFC 9116 ja. Die TR verlangt zwei Funktionspostfächer, psirt@ für Produkte und csirt@ für die eigene IT. Die beiden Rollen arbeiten eng zusammen, sind aber außer in Kleinstunternehmen mit verschiedenen Personen zu besetzen (4.3.1 b).

Brauche ich die Datei auf jeder Subdomain?

Die Datei gilt nur für die Domain, unter der sie liegt (RFC 9116 Abschnitt 3.1). Für jede Domain und Subdomain mit eigener Webseite ist eine eigene Datei sinnvoll, mindestens für die Haupt-Domain mit und ohne www.

Muss ich die Datei signieren?

RFC 9116 empfiehlt es, die TR verlangt es. Ohne Signatur kann niemand sicher sein, dass die Kontaktadressen wirklich von Ihnen stammen.

Wohin melden Forschende, wenn es keine security.txt gibt?

Oft an eine allgemeine Adresse, die niemand mit Sicherheitsthemen verbindet, oder gar nicht. Manche veröffentlichen die Lücke dann direkt. Genau das soll die Datei verhindern.

Quellen