security.txt erstellen: RFC 9116, Felder und Beispiel

Contact: mailto:admin@cyberscale.io
Expires: 2027-09-15T00:00:00.000Z
Preferred-Languages: de, en
Canonical: https://www.cyberscale.io/.well-known/security.txt

Das ist die vollständige Datei, die unter https://www.cyberscale.io/.well-known/security.txt liegt. Vier Zeilen, davon zwei Pflicht. Wer auf der Website eine Sicherheitslücke findet, ein offenes Verzeichnis, ein veraltetes Plugin, ein Formular, das fremde Mails verschickt, sieht hier, wohin er das melden soll, und bis wann diese Angabe gilt.

Eine security.txt ersetzt keine Sicherheitsmaßnahme, sie verkürzt den Weg zur Meldung. Ohne sie landet ein Hinweis im Kontaktformular, bei der allgemeinen Office-Adresse oder gar nicht. Das BSI nennt die Datei in seiner Pressemitteilung vom 06.08.2026 eine der „niedrigschwelligsten IT-Sicherheitsmaßnahmen überhaupt“ und zählt, wie wenige sie haben: 1,8 Prozent der Websitebetreiber in Deutschland.

Was in die Datei gehört#

RFC 9116 definiert acht Felder. Zwei sind Pflicht, der Rest hilft dem, der meldet.

Kommentare beginnen mit #. Das Format ist Klartext in UTF-8, eine Angabe je Zeile, Feldname, Doppelpunkt, Wert.

Zwei Felder verdienen einen zweiten Blick. Expires ist Pflicht, damit veraltete Dateien erkennbar sind. Eine Adresse, die vor drei Jahren eingetragen wurde und heute ins Leere läuft, schadet mehr, als sie nützt. RFC 9116 sagt das selbst: Keine Datei kann besser sein als eine mit veralteten Angaben. Contact sollte eine Adresse sein, die jemand liest. Eine eigene wie security@ ist sauber, eine bestehende, die im Betrieb ohnehin beantwortet wird, ist besser als eine neue, die niemand öffnet.

Der Generator auf securitytxt.org bietet zusätzlich ein Feld CSAF an. Das steht nicht in RFC 9116, sondern gehört zu einem Format, mit dem Hersteller Sicherheitshinweise maschinenlesbar veröffentlichen. Für eine Website ohne eigenes Produkt ist es überflüssig.

Erstellen und hochladen#

1. Die Datei schreiben. Mit jedem Texteditor, Dateiname security.txt:

Contact: mailto:security@beispiel.at
Contact: tel:+43-512-000000
Expires: 2027-09-30T22:00:00Z
Preferred-Languages: de, en
Canonical: https://www.beispiel.at/.well-known/security.txt

Telefonnummer und Domain sind hier Beispiele. Expires auf ein Datum knapp unter einem Jahr setzen, denselben Tag einen Monat vorher als Termin eintragen.

2. An die richtige Stelle legen. Der Pfad ist fest: /.well-known/security.txt. Der Ordner .well-known beginnt mit einem Punkt, manche FTP-Programme blenden ihn aus. Bei einer WordPress-Seite gehört er ins Hauptverzeichnis der Website, dorthin, wo auch wp-login.php liegt. Unter .well-known liegen oft schon andere Dateien, etwa die für die Let's-Encrypt-Bestätigung, die bleiben, wo sie sind. Auf Netlify, GitHub Pages oder Cloudflare Pages kommt die Datei in den Ordner, der veröffentlicht wird.

RFC 9116 erlaubt zusätzlich /security.txt im Hauptverzeichnis für ältere Werkzeuge, am besten als Weiterleitung auf den richtigen Pfad. Gibt es beide, gilt die unter /.well-known/.

3. Für jeden Hostnamen. Die Datei gilt laut RFC nur für den Namen, unter dem sie abgerufen wurde, nicht für Subdomains und nicht für die übergeordnete Domain. Wer beispiel.at und www.beispiel.at betreibt, braucht sie unter beiden, oder beispiel.at leitet wie die übrige Website auf www weiter. So macht es auch cyberscale.io. RFC 9116 rät Meldenden, Weiterleitungen genau anzusehen, weil sie auf eine fremde Domain führen könnten. Eine Weiterleitung innerhalb der eigenen Domain ist unverdächtig.

4. Signieren, wenn es passt. Empfohlen ist eine OpenPGP-Klartextsignatur, gpg --clearsign security.txt erzeugt sie. Sie beweist, dass die Angaben vom Betreiber stammen. Für einen kleinen Betrieb ohne gepflegten PGP-Schlüssel ist das kein Muss, ein Schlüssel, der abläuft oder dessen Passwort niemand mehr kennt, ist schlimmer als keine Signatur.

Prüfen, ob sie ankommt#

curl -sS -D - https://www.beispiel.at/.well-known/security.txt

Drei Dinge müssen stimmen:

• Status 200. Ein 404 heißt, die Datei liegt nicht dort, ein 403, dass der Server den Ordner sperrt. Manche Sicherheits-Plugins tun das mit allem, was mit einem Punkt beginnt.
• content-type: text/plain. RFC 9116 verlangt es.
• Im Körper stehen deine Zeilen, keine HTML-Seite. Das ist die häufigste Falle: Viele Websites liefern bei unbekannten Adressen ihre Fehlerseite mit Status 200 aus. Ein Werkzeug, das nur den Status prüft, meldet dann eine security.txt, die es nicht gibt.

Der Security-Scan prüft die Datei mit, und zwar auf den Inhalt: Gezählt wird nur eine Antwort, in der eine Contact-Zeile steht.

Messung: 146 Tiroler Domains gegen 1,8 Prozent#

In eigener Sache: Am 05.10.2026 um 08:12 UTC habe ich bei denselben 149 Tiroler Domains wie in meinen bisherigen Messungen, 34 Tourismusverbände und 115 Betriebe aus meiner Akquise-Liste, nach einer security.txt gefragt. Abgerufen wurde https://<domain>/.well-known/security.txt, dann /security.txt, dann beides unter www., einmal und so, wie ein Browser es tut. Als Datei zählte nur Text mit einem Contact-Feld. Drei Domains gibt es nicht mehr, bleiben 146.

• 1 Domain hat eine security.txt. Sie ist ordentlich aufgebaut, mit Ablaufdatum, Sprachangabe, Verweis auf eine Seite mit Melderegeln und einer zweiten Kontaktangabe als Webseite. In der ersten Contact-Zeile steht aber statt einer Mail-Adresse wörtlich ein Platzhalter, der darauf wartet, ersetzt zu werden. Wer meldet, kommt nur über die zweite Zeile weiter, eine Webseite.
• 14 Domains antworten mit Status 200, liefern aber eine HTML-Seite, meist die Fehler- oder Startseite. Ein Scanner, der nur auf den Status schaut, zählt sie mit.
• 124 antworten mit 404 oder einem anderen Fehlercode, 7 Websites waren nicht erreichbar.

Das sind 0,7 Prozent gegen 1,8 Prozent beim BSI. Direkt vergleichbar sind die Zahlen nicht: Das BSI hat im Projekt Cyberdome Websites in Deutschland gemessen und nennt in der Pressemitteilung weder Anzahl noch Auswahl. Meine Liste umfasst 146 Tiroler Domains aus Tourismus und Wirtschaft, keine Zufallsauswahl. Die Richtung ist trotzdem eindeutig: In Tirol hat praktisch niemand die Datei, und der eine Betrieb, der angefangen hat, hat die Vorlage nicht fertig ausgefüllt. Namen veröffentliche ich nicht.

Wem eine Meldung hilft#

Wer eine Lücke findet, hat drei Möglichkeiten: dem Betreiber Bescheid geben, einer Stelle wie einem CERT Bescheid geben oder schweigen. Die security.txt macht die erste einfach, und sie hilft auch bei der zweiten. CERT.at schreibt in einem Blogbeitrag vom 30.04.2024, dass es jeden Tag Hunderte Meldungen zu Sicherheitsproblemen im österreichischen Internet an die jeweiligen Betreiber weitergibt, und nennt den Standard security.txt als eine Möglichkeit, den Meldeweg festzulegen. Wer keinen nennt, wird über Umwege gesucht oder gar nicht erreicht.

Der Cyber Resilience Act, auf den das BSI in derselben Pressemitteilung verweist, betrifft Hersteller von Produkten mit digitalen Elementen, nicht den Betrieb einer Website. Die Meldepflichten für aktiv ausgenutzte Schwachstellen gelten laut BSI seit 11.09.2026, vollständig verpflichtend wird der CRA ab Dezember 2027. Für einen Tischler, eine Pension oder eine Zahnarztpraxis mit Website gibt es keine Pflicht zur security.txt. Sie ist eine Höflichkeit gegenüber denen, die helfen wollen, und kostet zehn Minuten.

Was nicht hilft#

Die Vorlage hochladen und nicht ausfüllen. Ein Platzhalter in Contact sagt jedem, der hinsieht, dass die Datei nie jemand gelesen hat.

Das Ablaufdatum vergessen. Eine Datei mit abgelaufenem Expires gilt als veraltet. Das Datum muss mindestens einmal im Jahr nachgezogen werden.

Eine Adresse, die niemand liest. security@ anzulegen und nirgends weiterzuleiten, ist schlechter als die normale Office-Adresse.

Die Datei nur unter /security.txt ablegen. Der feste Ort ist /.well-known/security.txt. Der alte Pfad ist nur als Ausweichstelle erlaubt.

Eine Fehlerseite mit Status 200. Sie verfälscht jede automatische Prüfung, nicht nur diese. Eine Adresse, die es nicht gibt, sollte mit 404 antworten.

Häufige Fragen#

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. Der Sicherheits-Check sieht sich an, was jemand von außen über deine Website und deine Domain erfährt, und sortiert die Funde nach Dringlichkeit. Ob eine security.txt ankommt, zeigt kostenlos und ohne Anmeldung der Security-Scan, wie die übrige Domain dasteht, der E-Mail-Check. Wie Server-Antworten mit Sicherheitsbezug sonst aussehen sollten, steht in Security-Header einrichten, und warum Transportverschlüsselung für Mails eine eigene Richtlinie braucht, in MTA-STS und TLS-RPT.

Stand 05.10.2026. Quellen an diesem Tag abgerufen, Messung am 05.10.2026.