Eine Sicherheitslücke auf der eigenen Webseite ist schon unangenehm genug. Noch problematischer wird es jedoch, wenn jemand die Schwachstelle entdeckt – und anschließend nicht weiß, wem er sie melden soll.
Soll die Meldung an info@example.de gehen? An den Webmaster? Den Datenschutzbeauftragten? Den IT-Support? Oder vielleicht über das allgemeine Kontaktformular zwischen einer Terminanfrage und einer Bewerbung landen?
Genau dieses Problem soll die security.txt lösen.
Die Datei stellt Webseitenbetreibern einen standardisierten Weg zur Verfügung, um Sicherheitsforschern, Administratoren und anderen Personen mitzuteilen, wie Sicherheitslücken verantwortungsvoll gemeldet werden können.
Der zugrunde liegende Standard ist RFC 9116 – A File Format to Aid in Security Vulnerability Disclosure.
Was ist eine security.txt?
Die security.txt ist eine einfache Textdatei, die auf einem Webserver unter einem fest definierten Pfad bereitgestellt wird.
Der standardmäßige Speicherort lautet:
https://example.de/.well-known/security.txt
Wer eine Sicherheitslücke auf example.de entdeckt, kann dadurch gezielt diese Adresse aufrufen und beispielsweise erfahren:
- Wer ist Ansprechpartner für Sicherheitslücken?
- Welche E-Mail-Adresse soll verwendet werden?
- Werden Meldungen auf Deutsch oder Englisch bevorzugt?
- Gibt es einen PGP-Schlüssel für verschlüsselte Meldungen?
- Existiert eine Vulnerability-Disclosure-Policy?
- Bis wann sind die Angaben in der Datei gültig?
Die security.txt kann damit als eine Art technische Kontaktkarte für Sicherheitsvorfälle und Schwachstellenmeldungen verstanden werden.
Sie ist allerdings kein Ersatz für ein Incident-Response-Verfahren oder ein Informationssicherheitsmanagementsystem.
RFC 9116
Die Spezifikation der security.txt wird in RFC 9116 beschrieben.
Der RFC definiert unter anderem den Aufbau der Datei, mögliche Felder, den vorgesehenen Speicherort und verschiedene Anforderungen an die Bereitstellung.
Der entscheidende Pfad ist:
/.well-known/security.txt
Für die Domain
https://www.example.de
ergibt sich somit:
https://www.example.de/.well-known/security.txt
Die Datei sollte über HTTPS bereitgestellt werden.
Eine minimale security.txt
Eine sehr einfache Variante könnte folgendermaßen aussehen:
Contact: mailto:security@example.de Expires: 2027-08-18T00:00:00Z
Damit werden bereits zwei wesentliche Informationen bereitgestellt.
Contact nennt den vorgesehenen Kommunikationsweg und Expires gibt an, bis wann die Informationen als gültig betrachtet werden sollen.
In der Praxis empfiehlt es sich jedoch, weitere Informationen aufzunehmen.
Beispiel einer umfangreicheren security.txt
Eine praxisnahe Datei könnte beispielsweise so aussehen:
Contact: mailto:security@example.de Expires: 2027-08-18T00:00:00Z Preferred-Languages: de, en Canonical: https://example.de/.well-known/security.txt Policy: https://example.de/security-policy/ Encryption: https://example.de/pgp/security.asc
Damit erhält ein Sicherheitsforscher bereits alle wichtigen Informationen für eine strukturierte Meldung.
Schauen wir uns die Felder genauer an.
Contact – Kontakt für Sicherheitsmeldungen
Das wichtigste Feld lautet:
Contact: mailto:security@example.de
Über Contact wird angegeben, wie Sicherheitslücken gemeldet werden sollen.
Eine eigene Funktionsadresse wie
security@example.de
ist dabei meist besser geeignet als die persönliche E-Mail-Adresse eines Administrators.
Der Grund ist einfach: Mitarbeiter wechseln, sind im Urlaub oder übernehmen andere Aufgaben. Eine Funktionsadresse kann dagegen dauerhaft bestehen und mehreren zuständigen Personen zugänglich gemacht werden.
Es können auch mehrere Contact-Einträge vorhanden sein.
Beispielsweise:
Contact: mailto:security@example.de Contact: https://example.de/security/report/
Damit können unterschiedliche Meldewege angeboten werden.
Expires – Gültigkeit der Angaben
Ein besonders wichtiges Feld ist:
Expires: 2027-08-18T00:00:00Z
Damit wird angegeben, wann die Informationen in der Datei ablaufen.
Das verhindert, dass eine vor vielen Jahren eingerichtete security.txt dauerhaft auf eine inzwischen nicht mehr existierende Mailadresse verweist.
Für den Betreiber bedeutet das allerdings auch:
Die security.txt muss regelmäßig überprüft und aktualisiert werden.
Die Pflege sollte daher Bestandteil eines normalen administrativen Prozesses sein.
Preferred-Languages – bevorzugte Sprachen
Mit
Preferred-Languages: de, en
kann angegeben werden, in welchen Sprachen Sicherheitsmeldungen bevorzugt entgegengenommen werden.
Für eine deutsche Organisation ist beispielsweise
Preferred-Languages: de, en
sinnvoll.
Damit wissen internationale Sicherheitsforscher sofort, dass auch englischsprachige Meldungen verarbeitet werden können.
Canonical – die offizielle Adresse
Das Feld Canonical gibt die kanonische Adresse der Datei an:
Canonical: https://example.de/.well-known/security.txt
Das ist insbesondere dann hilfreich, wenn dieselbe Datei über unterschiedliche URLs erreichbar sein könnte.
Die Angabe sollte auf die tatsächlich verwendete HTTPS-Adresse der security.txt zeigen.
Policy – Regeln für Sicherheitsforscher
Besonders interessant ist das Feld:
Policy: https://example.de/security-policy/
Damit kann auf eine ausführliche Vulnerability Disclosure Policy beziehungsweise Coordinated Vulnerability Disclosure Policy verwiesen werden.
Eine solche Seite kann beispielsweise erklären, welche Systeme untersucht werden dürfen, welche Tests ausgeschlossen sind, welche Informationen eine Schwachstellenmeldung enthalten sollte und wie die weitere Kommunikation erfolgt.
Beispielsweise könnte dort stehen, dass keine Denial-of-Service-Tests durchgeführt werden dürfen oder dass bei Tests keine Daten anderer Benutzer heruntergeladen werden sollen.
Die security.txt wird dadurch zum Einstiegspunkt in einen deutlich umfassenderen Vulnerability-Disclosure-Prozess.
Encryption – vertrauliche Meldungen ermöglichen
Sicherheitsmeldungen können sensible Informationen enthalten.
Ein Sicherheitsforscher könnte beispielsweise einen Proof of Concept, technische Details einer noch nicht behobenen Schwachstelle oder Informationen über betroffene Systeme übermitteln.
Deshalb kann ein verschlüsselter Kommunikationsweg sinnvoll sein.
Hierfür existiert das Feld Encryption:
Encryption: https://example.de/pgp/security.asc
Unter dieser Adresse könnte beispielsweise ein öffentlicher PGP-Schlüssel bereitgestellt werden.
Der Sicherheitsforscher kann seine Meldung anschließend verschlüsseln.
Acknowledgments – Danke für gefundene Schwachstellen
Manche Organisationen führen eine sogenannte Hall of Fame für Sicherheitsforscher.
Die entsprechende Seite kann über
Acknowledgments: https://example.de/security/thanks/
angegeben werden.
Dort können – natürlich nur nach entsprechender Abstimmung – Personen genannt werden, die verantwortungsvoll Schwachstellen gemeldet haben.
Eine solche Anerkennung kann eine konstruktive Sicherheitskultur unterstützen.
Hiring – Security-Fachkräfte gesucht
RFC 9116 sieht sogar die Möglichkeit vor, auf Stellenangebote hinzuweisen:
Hiring: https://example.de/jobs/security/
Das ist durchaus clever.
Wer gerade eine interessante Schwachstelle in der eigenen Infrastruktur gefunden hat, könnte schließlich auch fachlich interessant für die Organisation sein.
security.txt unter Apache bereitstellen
Auf einem Apache-Webserver kann die notwendige Verzeichnisstruktur beispielsweise im DocumentRoot angelegt werden.
Angenommen, die Webseite befindet sich unter:
/var/www/html/
Dann wird zunächst das Verzeichnis erstellt:
sudo mkdir -p /var/www/html/.well-known
Anschließend erstellen wir die Datei:
sudo nano /var/www/html/.well-known/security.txt
Beispielsweise mit folgendem Inhalt:
Contact: mailto:security@example.de Expires: 2027-08-18T00:00:00Z Preferred-Languages: de, en Canonical: https://example.de/.well-known/security.txt
Danach sollte die Datei über den Browser erreichbar sein:
https://example.de/.well-known/security.txt
security.txt mit Nginx
Auch bei Nginx kann die Datei einfach innerhalb des DocumentRoot abgelegt werden.
Beispielsweise:
sudo mkdir -p /var/www/example/.well-known
Danach:
sudo nano /var/www/example/.well-known/security.txt
Solange die normale Nginx-Konfiguration statische Dateien aus diesem Verzeichnis ausliefert, ist keine spezielle Konfiguration erforderlich.
Wichtig ist allerdings, dass vorhandene Regeln für versteckte Dateien nicht versehentlich den Zugriff auf .well-known blockieren.
WordPress und andere CMS
Auch bei WordPress muss die security.txt nicht zwingend durch ein Plugin erzeugt werden.
Bei einem klassischen Hosting kann einfach das Verzeichnis
.well-known
innerhalb des Webroots angelegt und dort die Datei
security.txt
gespeichert werden.
Wichtig ist anschließend nur die Kontrolle, ob
https://example.de/.well-known/security.txt
wirklich öffentlich erreichbar ist.
Bei verwalteten Plattformen, Reverse Proxies, CDNs oder speziellen Hosting-Angeboten kann die Vorgehensweise abweichen.
Die security.txt mit curl testen
Nach der Einrichtung sollte die Datei getestet werden.
Unter Linux eignet sich dafür beispielsweise:
curl https://example.de/.well-known/security.txt
Der Inhalt sollte direkt ausgegeben werden.
Zusätzlich können die HTTP-Header geprüft werden:
curl -I https://example.de/.well-known/security.txt
Im Idealfall erhalten wir:
HTTP/2 200
Eine Antwort wie
404 Not Found
zeigt dagegen, dass die Datei nicht am vorgesehenen Ort erreichbar ist.
Auch Weiterleitungen sollten überprüft werden.
Auf den Content-Type achten
Da es sich um eine Textdatei handelt, sollte der Webserver einen passenden MIME-Type ausliefern.
RFC 9116 sieht hierfür insbesondere text/plain vor.
Kontrollieren lässt sich dies beispielsweise mit:
curl -I https://example.de/.well-known/security.txt
In den Headern sollte dann ein entsprechender Content-Type erscheinen.
Häufige Fehler
Eine security.txt ist schnell eingerichtet. Trotzdem gibt es einige typische Fehler.
Falscher Speicherort
Die Datei wird beispielsweise nur hier abgelegt:
https://example.de/security.txt
Der standardisierte RFC-9116-Pfad lautet jedoch:
https://example.de/.well-known/security.txt
Veraltete Kontaktadresse
Eine Datei ist nur hilfreich, wenn die angegebene Adresse tatsächlich überwacht wird.
Contact: mailto:admin-von-2019@example.de
hilft wenig, wenn das Postfach seit Jahren niemand mehr liest.
Unbeaufsichtigtes security-Postfach
Eine Adresse wie
security@example.de
wirkt professionell – bringt aber keinen Sicherheitsgewinn, wenn niemand das Postfach überwacht.
Es sollte deshalb organisatorisch geregelt sein, wer eingehende Meldungen bearbeitet und wer die Vertretung übernimmt.
Expires vergessen
Die Gültigkeitsangabe zwingt Betreiber indirekt dazu, die Informationen regelmäßig zu überprüfen.
Das ist gewollt.
Die security.txt sollte deshalb in bestehende Wartungs- und Kontrollprozesse aufgenommen werden.
security.txt ohne internen Prozess
Der vielleicht größte Fehler besteht darin, eine perfekte security.txt bereitzustellen, ohne intern zu klären, was anschließend mit einer Meldung passiert.
Eine eingehende Nachricht wie
„Auf Ihrem öffentlich erreichbaren Server lässt sich die Authentifizierung umgehen.“
sollte nicht erst drei Wochen zwischen Helpdesk, Öffentlichkeitsarbeit und Webagentur weitergeleitet werden.
Vom Contact-Feld zum Schwachstellenmanagement
Genau an dieser Stelle zeigt sich, dass security.txt eigentlich nur der sichtbare Teil eines größeren Prozesses ist.
Eine Organisation sollte intern zumindest festlegen:
- Wer nimmt die Meldung entgegen?
- Wer bewertet die Schwachstelle?
- Wer informiert die verantwortlichen Administratoren?
- Wie wird die Kritikalität bewertet?
- Wie wird der Eingang gegenüber dem Melder bestätigt?
- Welche internen Eskalationswege existieren?
- Wann wird die Schwachstelle behoben?
- Wie wird die Behebung getestet?
- Wer kommuniziert anschließend mit dem Finder?
- Muss der Vorgang zusätzlich als Sicherheitsvorfall behandelt werden?
Damit wird aus einer simplen Textdatei ein Baustein eines strukturierten Vulnerability-Management-Prozesses.
security.txt und NIS2
Auch im Zusammenhang mit NIS2 ist das Thema interessant.
Eine security.txt allein macht eine Organisation selbstverständlich nicht NIS2-konform. Sie kann jedoch einen sinnvollen Baustein innerhalb eines umfassenden Sicherheitsmanagements darstellen.
NIS2 legt einen deutlich stärkeren Fokus auf systematisches Risikomanagement, Sicherheitsmaßnahmen, Incident Handling und den Umgang mit Schwachstellen.
Ein klar definierter externer Meldeweg unterstützt dabei insbesondere einen wichtigen Gedanken:
Schwachstellen müssen erkannt, bewertet, kommuniziert und behandelt werden können.
Die technische Veröffentlichung einer security.txt sollte deshalb idealerweise mit internen Prozessen für Vulnerability Management und Incident Response verbunden werden.
security.txt ist kein Freibrief für Hacker
Ein häufiges Missverständnis sollte ebenfalls vermieden werden.
Die Veröffentlichung einer security.txt bedeutet nicht:
„Jeder darf unsere Systeme nach Belieben angreifen.“
Sie stellt zunächst lediglich einen standardisierten Kommunikationsweg zur Verfügung.
Wer ausdrücklich Regeln für Sicherheitsforschung definieren möchte, sollte zusätzlich eine entsprechende Vulnerability Disclosure Policy veröffentlichen und dort möglichst eindeutig beschreiben, was erlaubt und was nicht erlaubt ist.
Ein praxistaugliches Beispiel
Für viele kleinere Unternehmen und Organisationen könnte bereits folgende Variante ein guter Ausgangspunkt sein:
Contact: mailto:security@example.de Expires: 2027-08-18T00:00:00Z Preferred-Languages: de, en Canonical: https://example.de/.well-known/security.txt Policy: https://example.de/security/
Dazu sollte organisatorisch sichergestellt werden, dass security@example.de zuverlässig überwacht wird und eingehende Meldungen unmittelbar an die zuständigen Stellen gelangen.
Damit ist die technische Seite erstaunlich schnell umgesetzt.
Eine security.txt ist technisch unspektakulär: ein Verzeichnis, eine kleine Textdatei und einige standardisierte Felder.
Ihr Nutzen kann trotzdem erheblich sein.
Wer eine Sicherheitslücke entdeckt, muss nicht erst herausfinden, ob Webmaster, Support, Datenschutzbeauftragter oder allgemeines Kontaktformular der richtige Ansprechpartner ist. Stattdessen existiert unter
/.well-known/security.txt
ein standardisierter Einstiegspunkt.
Besonders für Unternehmen, Behörden, Kommunen und Betreiber größerer Webangebote ist die Einrichtung deshalb empfehlenswert.
Entscheidend ist allerdings, die Datei nicht isoliert zu betrachten. Hinter einer Adresse wie
security@example.de
muss ein funktionierender Prozess stehen.
Denn die beste security.txt nützt wenig, wenn die Sicherheitsmeldung anschließend ungelesen im Postfach liegt.
Richtig umgesetzt ist RFC 9116 dagegen ein kleines, einfaches und wirkungsvolles Element eines professionellen Schwachstellenmanagements.
