security.txt nach RFC 9116
01/10/2026 · 
Das Wichtigste auf einen Blick
Eine security.txt nach RFC 9116 ist eine kleine Textdatei. Sie zeigt Sicherheitsforschenden, wohin sie Schwachstellen melden sollen. Pflicht sind nur zwei Felder: Contact und Expires. Die Datei muss per HTTPS als text/plain unter /.well-known/security.txt erreichbar sein. Das Root-Verzeichnis allein reicht nicht. Das Ablaufdatum sollte weniger als ein Jahr in der Zukunft liegen. Das BSI empfiehlt die Datei ausdrücklich. Für Hersteller ist sie der naheliegende Weg, den Kontaktpunkt zu veröffentlichen, den der Cyber Resilience Act verlangt.
Vor ein paar Tagen hat ein Verzeichnisdienst, in dem hosting.de gelistet ist, unseren Sicherheitskontakt als verifiziert markiert. Den Eintrag hatte ein Mitarbeiter des Dienstes allerdings von Hand vorgenommen: Er übernahm security@hosting.de und den Link zu unserer Policy-Seite aus https://www.hosting.de/security.txt.
Der Haken: Die automatische Nachprüfung des Dienstes liest https://www.hosting.de/.well-known/security.txt, also genau den Ort, den RFC 9116 vorschreibt. Diese Adresse lieferte einen 404. Ohne Korrektur wäre unser Eintrag bei der nächsten Prüfung in rund drei Monaten als abgelaufen markiert worden. Außerdem wies der Dienst auf unser Expires-Datum hin. Es stand auf 2040, der Standard empfiehlt weniger als ein Jahr.
Wir sind ein Hoster und erklären anderen Leuten, wie man Webserver konfiguriert. Trotzdem lag unsere Datei am falschen Ort. Weil das vermutlich nicht nur uns passiert, zeigen wir Dir hier, wie eine security.txt nach RFC 9116 aussieht, wo sie liegen muss und woran Du erkennst, dass sie funktioniert.
Was RFC 9116 festlegt
Die IETF hat RFC 9116 im April 2022 veröffentlicht. Geschrieben haben ihn Edwin Foudil und Yakov Shafranovich. Das Dokument definiert ein maschinenlesbares Format, mit dem Organisationen beschreiben, wie Sicherheitsforschende ihnen Schwachstellen melden können. Die Idee ähnelt der robots.txt: eine einfache Textdatei an einer festen Adresse, die Menschen und Programme gleichermaßen lesen.
Formal ist RFC 9116 als “Informational” eingestuft und hat den Standardisierungsprozess der IETF nicht durchlaufen. In der Praxis ändert das wenig. Scanner, Verzeichnisdienste und Behörden wie das BSI richten sich danach, und die IANA führt eine eigene Registry für die Felder.
Vorher gab es nur die Konvention aus RFC 2142, eine Adresse security@domain einzurichten. Die funktioniert bis heute. Sie bietet aber genau einen Kanal und keinen Platz für eine Richtlinie, einen PGP-Schlüssel oder bevorzugte Sprachen.
Warum info@ als Sicherheitskontakt nicht reicht
Wer eine Lücke findet, muss den richtigen Menschen erreichen. Das BSI zählt die Suche nach dem passenden Ansprechpartner zu den größten Hürden bei der koordinierten Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure, CVD). Findet das CERT-Bund auf einer Website keinen erkennbaren Sicherheitskontakt, schreibt es an die Adressen, die es findet, etwa datenschutz@ oder info@. Dort liegt die Meldung dann zwischen Newsletter-Abmeldungen und Bewerbungen.
Das BSI empfiehlt Unternehmen deshalb dringend, eine security.txt bereitzustellen. Nach einer Meldung vom CERT-Bund erwartet es eine Eingangsbestätigung innerhalb von drei Werktagen. Die schaffst Du nur, wenn die Mail beim richtigen Team bzw. Mitarbeiter ankommt.
Verbreitet ist die Datei trotzdem kaum. Das Portal watson.ch fand 2022 nur bei rund 40 der 1.000 meistbesuchten Webadressen der Schweiz eine security.txt. Ein Forschungsteam um Finn Eckstein hat alle deutschen Hochschulen per Mail auf den Standard hingewiesen. Die Zahl der Dateien hat sich danach verdreifacht.
Die Felder im Überblick
| Feld | Pflicht | Wofür | Beispielwert |
|---|---|---|---|
| Contact | ja, mindestens einmal | Meldeweg per Mail, Telefon oder Formular | mailto:security@example.de |
| Expires | ja, genau einmal | Datum, ab dem die Angaben als veraltet gelten | 2027-08-31T22:00:00Z |
| Encryption | nein | Link zum Schlüssel, nie der Schlüssel selbst | https://www.example.de/pgp-key.txt |
| Preferred-Languages | nein | Sprachen für Meldungen, ohne Angabe gilt Englisch | de, en |
| Canonical | nein | Adresse, unter der diese Datei gilt | https://www.example.de/.well-known/security.txt |
| Policy | nein | Deine Offenlegungsrichtlinie | https://www.example.de/sicherheit/ |
| Acknowledgments | nein | Seite, auf der Du Meldende würdigst | https://www.example.de/danke/ |
| Hiring | nein | Stellenangebote im Security-Bereich | https://www.example.de/jobs/ |
Beim Nachlesen im RFC sind uns drei Details aufgefallen, die in vielen Anleitungen fehlen. Bei Contact zählt die Reihenfolge: Die erste Zeile ist der bevorzugte Weg. Bei Preferred-Languages zählt sie nicht, alle genannten Sprachen sind gleichrangig. Und das Feld heißt Acknowledgments, in amerikanischer Schreibweise ohne “e”. Schreibst Du “Acknowledgements”, behandelt ein Parser das Feld als unbekannt und ignoriert es.
Außerdem gilt für alle Links in der Datei: Sie beginnen mit https://. Mailadressen stehen als mailto:, Telefonnummern als tel:.
Der Pfad entscheidet: /.well-known/ statt Root-Verzeichnis
Hier lag unser Fehler. RFC 9116 schreibt für Webdienste vor, dass die Datei unter /.well-known/security.txt liegt. Root ist nur aus Kompatibilitätsgründen erlaubt, als zusätzliche Kopie oder als Weiterleitung auf die Datei unter /.well-known/. Gibt es beide, gilt die unter /.well-known/.
Dazu kommen drei technische Bedingungen. Die Datei wird über HTTPS ausgeliefert, mit dem Content-Type text/plain und dem Zeichensatz UTF-8.
Der Verzeichnisdienst schlug zwei Lösungen vor: die Datei zusätzlich unter /.well-known/ ausliefern oder von dort per 301 auf die bestehende Datei weiterleiten. Wir halten die umgekehrte Richtung für sauberer. Die echte Datei liegt unter /.well-known/security.txt, und die alte Adresse im Wurzelverzeichnis leitet dorthin weiter. So liegt die Datei dort, wo der RFC sie erwartet, und alte Links funktionieren weiter.
Auf Apache reichen dafür zwei Zeilen in der .htaccess:
Redirect 301 /security.txt /.well-known/security.txt
AddCharset utf-8 .txt
Unter nginx sieht es so aus:
location = /security.txt {
return 301 /.well-known/security.txt;
}
location = /.well-known/security.txt {
charset utf-8;
}
Ein Stolperstein aus der Praxis: Viele FTP-Clients blenden Ordner mit einem Punkt am Anfang standardmäßig aus. Wenn Du /.well-known/ nicht siehst, heißt das nicht, dass es ihn nicht gibt. Bei Websites mit Let’s-Encrypt-Zertifikat existiert er oft schon.
Expires: Warum 2040 keine gute Idee ist
Wir hatten 2040 eingetragen, damit die Datei nie abläuft. Das Motiv ist verständlich, verfehlt aber den Zweck des Feldes. RFC 9116 empfiehlt ein Datum weniger als ein Jahr in der Zukunft. Die Begründung steht im Kapitel über veraltete Informationen: Stimmen die Kontaktdaten nicht mehr, landen Meldungen bei den falschen Leuten, und Details zu einer Lücke gelangen an Dritte. Laut RFC ist gar keine security.txt unter Umständen besser als eine mit veralteten Angaben.
Ein Datum in 14 Jahren sagt einem Forscher nichts darüber, ob das Postfach noch jemand liest. Ein Datum in zehn Monaten zeigt, dass sich jemand kümmert. Trag deshalb ein Datum in zehn bis elf Monaten ein und leg Dir vier Wochen vorher eine Erinnerung an. Beim Erneuern prüfst Du gleich mit, ob Postfach, Policy-Link und Schlüssel noch stimmen. Das Feld darf übrigens nur einmal in der Datei stehen.
So richtest Du Deine security.txt ein
1. Funktionspostfach anlegen. Nimm security@deinedomain.de und keine persönliche Adresse, die beim nächsten Jobwechsel ins Leere läuft. Das BSI rät, Infrastruktur und Produkte zu trennen: security@ für Lücken auf Deiner Website, psirt@ oder productsecurity@ für Software, die Du vertreibst.
2. Datei schreiben. Ein vollständiges Beispiel mit Pflicht- und Empfehlungsfeldern:
# Sicherheitskontakt für example.de
Contact: mailto:security@example.de
Contact: https://www.example.de/sicherheit/melden/
Expires: 2027-08-31T22:00:00Z
Encryption: https://www.example.de/pgp-key.txt
Preferred-Languages: de, en
Canonical: https://www.example.de/.well-known/security.txt
Policy: https://www.example.de/sicherheit/
Zeilen mit # am Anfang sind Kommentare. Speichere die Datei als UTF-8.
3. Hochladen. Lege die Datei per FTP oder SSH in den Ordner /.well-known/ Deines Webroots. HTTPS ist Voraussetzung. Falls Dein Server noch kein Zertifikat hat, zeigen wir in unserer Anleitung, wie Du ein SSL-Zertifikat auf einem VPS installierst.
4. Weiterleitung setzen. Leite /security.txt wie oben gezeigt per 301 auf /.well-known/security.txt um.
5. Prüfen. Mit curl siehst Du Statuscode und Content-Type auf einen Blick:
curl -sI https://www.example.de/.well-known/security.txt
In der Antwort sollten 200 und text/plain; charset=utf-8 stehen. Zusätzlich lohnt ein Online-Validator wie securitytxt.org, der auch Syntax und Ablaufdatum prüft.
6. Optional signieren. Der RFC empfiehlt eine OpenPGP-Signatur (gpg –clearsign security.txt) in Kombination mit dem Canonical-Feld. Dann können Forschende prüfen, ob die Datei wirklich von Dir stammt.
Gilt die Datei auch für Subdomains?
Nein. Eine security.txt gilt nur für die Domain oder IP-Adresse, unter der sie abgerufen wurde, nicht für Subdomains und nicht für übergeordnete Domains. Betreibst Du shop.example.de und blog.example.de, braucht jede Subdomain ihre eigene Datei. Das betrifft vor allem Setups, in denen mehrere Websites auf einem einzigen Server laufen.
Wer Webspace an mehrere Nutzer vergibt, sollte die Pfade /security.txt und /.well-known/security.txt reservieren. Sonst kann ein Nutzer dort eine eigene Datei ablegen und Meldungen auf sich umleiten. Genau davor warnt der RFC im Abschnitt über Mehrbenutzerumgebungen.
Typische Fehler und ihre Folgen
| Fehler | Folge | Lösung |
|---|---|---|
| Datei nur unter /security.txt | Automatische Prüfungen finden nichts | Datei nach /.well-known/, Wurzel per 301 weiterleiten |
| Expires Jahre in der Zukunft | Datei wirkt ungepflegt | Datum unter einem Jahr, Erinnerung setzen |
| Expires überschritten | Angaben gelten als veraltet | Rechtzeitig erneuern |
| Contact ohne mailto: | Kein gültiger URI | mailto:, tel: oder https:// verwenden |
| Links mit http:// | Verstoß gegen den RFC | Alle Links auf https:// |
| Auslieferung als text/html | Parser lehnen die Datei ab | Content-Type prüfen |
| Persönliche Mailadresse | Meldungen gehen bei Personalwechsel verloren | Funktionspostfach |
| “Acknowledgements” mit e | Feld wird ignoriert | “Acknowledgments” schreiben |
security.txt und der Cyber Resilience Act
Hersteller von Produkten mit digitalen Elementen müssen nach dem Cyber Resilience Act (CRA) eine Kontaktstelle für Schwachstellenmeldungen veröffentlichen. Die Verordnung nennt security.txt nicht beim Namen. Die Datei ist aber der übliche und vom BSI empfohlene Weg, diese Kontaktstelle maschinenlesbar bereitzustellen. Wer sie gepflegt hat, kann in der technischen Dokumentation direkt darauf verweisen. Für die konkrete Umsetzung Deiner CRA-Pflichten solltest Du trotzdem eine rechtliche Beratung hinzuziehen.
Was die Datei nicht leistet
Eine security.txt ist keine Erlaubnis für Sicherheitstests. Der RFC stellt klar, dass weder ihr Vorhandensein noch ihr Fehlen etwas über Testfreigaben aussagt. Ob und was getestet werden darf, gehört in Deine Policy.
Rechne außerdem mit mehr Post. Automatische Scanner verschicken Meldungen ohne menschliche Prüfung, und manche davon sind wertlos. Plane Zeit für die Sichtung ein. Das BSI betont in seiner Empfehlung BSI-CS 149, dass die Datei bestehende Kanäle und Richtlinien ergänzt und nicht ersetzt.
Und schließlich kann ein Angreifer, der Deine Website kompromittiert hat, auch die security.txt ändern. Canonical-Feld, Signatur und eine regelmäßige Kontrolle der Datei machen das sichtbar. Wie Du Deinen Server grundsätzlich absicherst, beschreiben wir in unseren Best Practices für die Sicherheit von VPS-Hosting.
Fazit
Eine security.txt besteht aus einer Handvoll Zeilen, und trotzdem hatten wir zwei Fehler darin. Beide haben niemandem geschadet, weil ein Mensch beim Verzeichnisdienst genauer hingesehen hat als sein Prüfskript. Darauf solltest Du Dich nicht verlassen. Ruf jetzt https://deinedomain.de/.well-known/security.txt auf. Wenn dort ein 404 kommt, weißt Du, was als Nächstes zu tun ist.
Du willst Konfigurationen wie diese selbst in der Hand haben? Auf einem vServer oder Cloud Server hast Du vollen Zugriff auf Webserver und .htaccess. Wenn Dir der Betrieb zu viel Arbeit ist, übernehmen wir ihn mit einem Managed Cloud Server.
Häufige Fragen
Welche Felder sind in einer security.txt Pflicht? Nach RFC 9116 sind nur Contact und Expires Pflicht. Contact muss mindestens einmal vorkommen, Expires genau einmal. Alle anderen Felder wie Encryption, Policy, Canonical oder Preferred-Languages sind optional.
Wo muss die security.txt liegen? Für Websites muss die Datei unter /.well-known/security.txt liegen, ausgeliefert per HTTPS als text/plain mit UTF-8. Eine Kopie oder Weiterleitung im Wurzelverzeichnis ist zusätzlich erlaubt. Liegen zwei Dateien vor, gilt die unter /.well-known/.
Wie weit darf das Expires-Datum in der Zukunft liegen? RFC 9116 empfiehlt weniger als ein Jahr. Das Format folgt RFC 3339, zum Beispiel 2027-08-31T22:00:00Z. Ein kurzes Ablaufdatum zwingt Dich, die Kontaktdaten regelmäßig zu prüfen.
Gilt eine security.txt auch für Subdomains? Nein. Die Datei gilt nur für die Domain oder IP-Adresse, unter der sie abgerufen wurde. Jede Subdomain braucht eine eigene security.txt.
Erlaubt eine security.txt Sicherheitstests an meiner Website? Nein. Laut RFC 9116 sagt die Datei nichts über Testfreigaben aus. Ob Tests erlaubt sind, regelst Du in Deiner Offenlegungsrichtlinie, auf die das Feld Policy verweist.
