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 Behörden lesen die Datei automatisch.

Zwei Dinge regelt der Standard 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, höchstens ein Jahr voraus, T und Z groß (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 Kontaktadresse, 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 der weltweite Standard 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 (Verordnung (EU) 2024/2847) verlangt eine Kontaktadresse für Schwachstellenmeldungen (Anhang I Teil II Nummer 6), legt aber kein Format fest, und die TR ist die einzige behördliche Beschreibung dafür. 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 beweist, dass die Datei von Ihnen stammt und nicht von jemandem, der Meldungen umleiten will. Sie brauchen dazu GnuPG. Die TR empfiehlt einen eigenen Schlüssel nur zum Signieren (4.2.10 b), der höchstens fünf Jahre gilt (4.2.10 e). So legen Sie ihn an, hier mit RSA 3072 Bit und zwei Jahren Laufzeit:

gpg --quick-generate-key "Beispiel GmbH security.txt <security@beispiel.de>" rsa3072 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>" rsa3072 sign 2y
gpg --quick-add-key <Fingerabdruck> rsa3072 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.

Nach jeder Änderung an der Datei neu signieren. Schon ein geändertes Zeilenende oder ein Leerzeichen am Zeilenende macht die Signatur ungültig. Laden Sie die Datei deshalb binär hoch, nicht als Text.

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 einer der häufigsten Fehler, die der Check findet.

Cloudflare und andere Bot-Schutze

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 werten Prüfdienste sie als ungültig. 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.

Wer sich darum nicht kümmern will: Die Überwachung prüft die Datei jeden Tag und erinnert rechtzeitig, für 60 Euro im Jahr je Domain.

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; kleines t oder z im Datum.
  • Canonical zeigt woandershin, etwa auf firma.de, während die Datei unter www.firma.de liegt.
  • Acknowledgements statt Acknowledgments: Das Feld schreibt sich amerikanisch.
  • E-Mail ohne mailto: im Feld Contact.
  • Encryption zeigt auf eine Seite statt direkt auf die .asc-Datei.
  • 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.

Häufige Fragen

Ist die security.txt Pflicht?

Ein Gesetz schreibt die Datei nicht vor. Der Cyber Resilience Act verlangt von Herstellern 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.

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, die TR höchstens ein Jahr. 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. Beide dürfen beim selben Team ankommen.

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