security.txt ist eine bewährte Web-Sicherheitspraxis, die von der IETF (Internet Engineering Task Force) in RFC 9116 formal standardisiert wurde. Ziel ist es, Webseiten eine einheitliche, standardisierte Möglichkeit zur Veröffentlichung von Sicherheitskontaktinformationen zu bieten. Einfach ausgedrückt: Es handelt sich um eine Textdatei an einem festen Pfad auf der Webseite, die Sicherheitsforschern (White-Hat-Hackern) sagt: „Wenn Sie eine Sicherheitslücke auf meiner Webseite finden, hier sind die Kontaktmöglichkeiten, hier ist unser Verschlüsselungsschlüssel, hier sind unsere Offenlegungsrichtlinien – wir freuen uns über Ihre Meldung."
Vor der Einführung des security.txt-Standards waren Sicherheitskontaktinformationen von Webseiten willkürlich und uneinheitlich. Manche Webseiten hatten überhaupt keine Sicherheitskontaktangaben, andere versteckten sie auf irgendeiner Seite, wieder andere gaben nur eine info@-E-Mail-Adresse an, die niemand las, und bei manchen musste man über LinkedIn umständlich nach dem Sicherheitsteam suchen. Dies führte zu einem schwerwiegenden Problem: Wenn gutgläubige Sicherheitsforscher eine Schwachstelle entdeckten, fanden sie oft keinen richtigen Kanal zur Meldung. Die Folge: Viele Schwachstellen blieben unbemerkt und ungefixt, bis sie von böswilligen Hackern entdeckt und ausgenutzt wurden. security.txt wurde entwickelt, um genau dieses „Letzte-Meile-Problem" zu lösen.
Das Konzept von security.txt wurde erstmals 2017 von den Sicherheitsforschern EdOverflow und Yakov Shafranovich vorgeschlagen und fand schnell breite Unterstützung in der Branche. Im April 2022 wurde security.txt von der IETF offiziell als RFC 9116-Standard verabschiedet und ist damit ein international anerkannter Web-Sicherheitsstandard. Heute haben große Technologieunternehmen wie Google, GitHub, Meta (Facebook), LinkedIn, Cloudflare sowie Regierungsbehörden wie die britische Regierung, die US-CISA (Cybersecurity and Infrastructure Security Agency), das BSI (Bundesamt für Sicherheit in der Informationstechnik) und Regierungen in Frankreich, Italien, den Niederlanden und dem Australian Cyber Security Centre security.txt auf ihren offiziellen Webseiten bereitgestellt und empfehlen anderen Organisationen öffentlich die Übernahme.
Das Kerndesign der security.txt-Datei ist sehr einfach – es handelt sich um eine reine Textdatei, die aus einer Reihe von Zeilen im Format „Feldname: Wert" besteht, ähnlich wie HTTP-Header. Der Standard definiert zwei Pflichtfelder: Contact (Sicherheitskontaktangaben, mehrere möglich) und Expires (Ablaufzeit der Datei); sowie mehrere optionale Felder: Encryption (URL zum PGP-Verschlüsselungsschlüssel), Acknowledgments (URL zur Danksagungsseite), Policy (URL zur Schwachstellenoffenlegungsrichtlinie), Hiring (URL zu Sicherheitsstellen), Canonical (kanonische URL der Datei), Preferred-Languages (unterstützte Meldesprachen), CSAF (URL zu Metadaten des Common Security Advisory Framework). Dieses einfache Format ermöglicht sowohl Menschen als auch Maschinen eine einfache Auswertung.
Warum ist die Bereitstellung von security.txt so wichtig? Erstens senkt es die Hürde für Schwachstellenmeldungen: Sicherheitsforscher müssen nicht viel Zeit mit der Suche nach Kontaktangaben verbringen, sondern finden den richtigen Meldeweg mit einem Klick. Zweitens signalisiert es eine positive Einstellung der Organisation zur Sicherheit – eine Webseite mit security.txt sagt im Grunde: „Wir nehmen Sicherheit ernst und freuen uns über verantwortungsvolle Meldungen." Drittens reduziert es das Risiko einer öffentlichen Offenlegung oder Ausnutzung von Schwachstellen: Wenn Forscher einen offiziellen Kanal haben, werden sie nicht wegen fehlender Kontaktmöglichkeit Schwachstellen direkt auf Twitter oder GitHub veröffentlichen. Viertens ist die Einrichtung eines Schwachstellenmeldekanals in vielen branchenspezifischen Regularien (Finanzwesen, Gesundheit, Behörden) bereits eine Compliance-Anforderung.
Bei der Bereitstellung von security.txt sind einige wichtige Details zu beachten. Erstens muss der Pfad korrekt sein: Der Standardpfad ist /.well-known/security.txt, optional kann eine Kopie als /security.txt im Stammverzeichnis als Fallback abgelegt werden. Das .well-known-Verzeichnis ist ein in RFC 8615 definiertes Standardverzeichnis für „bekannte Ressourcen" – auch andere Standarddateien wie robots.txt werden an entsprechenden Stellen platziert. Zweitens muss die Bereitstellung über HTTPS erfolgen, unverschlüsseltes HTTP gilt als unsicher. Drittens muss der Content-Type text/plain sein, nicht text/html oder ein anderer Typ. Viertens sollte security.txt keine domänenübergreifenden Umleitungen durchführen – wenn https://example.com/.well-known/security.txt zu https://andere-domain.com/security.txt umleitet, betrachten Forscher und automatisierte Tools dies als verdächtig. Fünftens: Vergessen Sie nicht, das Expires-Feld zu setzen und regelmäßig zu aktualisieren – eine abgelaufene security.txt gilt als unzuverlässig.
Das Contact-Feld ist das wichtigste Feld in security.txt und das einzige wirklich unverzichtbare Feld (Expires ist ebenfalls Pflicht, aber nur ein Zeitstempel). Contact unterstützt drei URI-Formate: mailto: für E-Mail-Adressen, https:// für Web-Links (z. B. ein Formular für Sicherheitsmeldungen), tel: für Telefonnummern. Es wird dringend empfohlen, mindestens eine mailto-E-Mail-Adresse und einen https-Link zu einem Formular bereitzustellen – Formulare schützen vor Bot-Spam, E-Mails erleichtern es Forschern, verschlüsselte Berichte direkt zu senden. Mehrere Kontaktangaben können mehrzeilig aufgelistet werden, z. B. gleichzeitig die E-Mail-Adresse des Sicherheitsteams, des Sicherheitsverantwortlichen und der Link zu einer Drittanbieter-Plattform für Schwachstellenmeldungen.
Obwohl das Encryption-Feld optional ist, ist es in der Praxis sehr wichtig. Wenn Sicherheitsforscher eine schwerwiegende Schwachstelle entdecken (z. B. Datenleck von Benutzerdaten, Remote Code Execution), möchten sie Schwachstellendetails auf keinen Fall per unverschlüsselter E-Mail senden – da E-Mails während der Übertragung mehrere Server passieren und an jeder Stelle abgehört werden können. Die PGP-Verschlüsselung (Pretty Good Privacy) ist der branchenübliche Standard für sichere Kommunikation. Sie müssen nur ein PGP-Schlüsselpaar generieren, den Public Key auf Ihrer Webseite ablegen (z. B. unter /.well-known/pgp-key.txt) und diese URL in das Encryption-Feld eintragen. Forscher verschlüsseln den Bericht mit Ihrem Public Key – nur wer den zugehörigen Private Key besitzt, kann den Bericht entschlüsseln und lesen.
Das Policy-Feld verlinkt auf Ihre Seite zur Schwachstellenoffenlegungsrichtlinie (Vulnerability Disclosure Policy, VDP), die für das Vertrauen der Forscher entscheidend ist. Eine gute VDP sollte klar erläutern: Testumfang (welche Systeme zum Testumfang gehören und welche nicht), erlaubte Testmethoden (z. B. SQL-Injection/XSS-Tests erlaubt, aber DDoS/Social Engineering/Zugriff auf echte Benutzerdaten verboten), zugesagte Reaktionszeiten (z. B. „Wir bestätigen den Erhalt Ihrer Meldung innerhalb von 3 Werktagen"), ob Sie Schwachstellenprämien zahlen sowie rechtliche Safe-Harbor-Zusagen (ausdrücklich keine Strafverfolgung von regelkonformen, gutgläubigen Forschern). International gibt es viele VDP-Vorlagen zur Orientierung, auch die US-CISA stellt Open-Source-VDP-Vorlagen bereit.
Neben der Sicherheitskontaktaufnahme selbst gibt es in security.txt einige „Überraschungsfelder". Das Acknowledgments-Feld baut eine Hall of Fame (Sicherheits-Ruhmeshalle) auf – öffentliche Danksagung an Forscher, die Ihnen bei der Entdeckung von Schwachstellen geholfen haben. Dies ist Anerkennung ihrer Arbeit und zugleich Gemeinschaftsaufbau. Das Hiring-Feld ist ein sehr kluges Konzept: Wer Schwachstellen auf Ihrer Webseite findet, ist selbst ein hervorragendes Sicherheitstalent – ein Stellenlink in security.txt ist der zielgerichtetste Kanal zur Rekrutierung von Sicherheitstalenten. Viele Unternehmen haben über security.txt hervorragende Sicherheitsingenieure eingestellt. Das Canonical-Feld dient der Sicherheit – es verhindert, dass Angreifer Ihre security.txt unter anderen Domains fälschen.
Zur häufigen Sorge vor Spam: Tatsächlich berichten die meisten Organisationen, die security.txt bereits bereitgestellt haben, von keinem nennenswerten Anstieg von Spam. Dies hat folgende Gründe: Erstens beziehen Spam-Versender E-Mail-Adressen normalerweise nicht durch das Crawlen von security.txt; zweitens können https://-Formular-Links anstelle direkter mailto-E-Mails verwendet werden – mit Captchas auf dem Formular lassen sich Bots vollständig blockieren; drittens sind spezielle Sicherheits-E-Mail-Adressen (z. B. sicherheit@) üblicherweise mit strengen Spamfiltern konfiguriert. Im Vergleich dazu sind die Kosten für schwerwiegende Schwachstellenmeldungen, die aufgrund fehlender Kontaktmöglichkeit verpasst werden, weitaus höher als ein potenziell geringfügig erhöhtes Spamaufkommen.
Dieser Generator wurde streng nach dem RFC 9116-Standard entwickelt, alle Ausgabeformate sind standardisiert: Das Contact-Feld erkennt Präfixe automatisch, das Expires-Feld verwendet das Standard-UTC-Zeitformat nach ISO 8601, Preferred-Languages wird automatisch entsprechend der von Ihnen verwendeten Sprache gesetzt. Die generierten Inhalte können direkt kopiert und unter dem Pfad /.well-known/security.txt bereitgestellt werden, ohne dass Änderungen erforderlich sind. Gleichzeitig erfolgen alle Konfigurationen lokal in Ihrem Browser und werden an keine Server gesendet – Ihre Sicherheitskontaktinformationen verbleiben stets auf Ihrem Gerät. Die Bereitstellung von security.txt dauert nur 5 Minuten, aber der aufgebaute sichere Kommunikationskanal kann Ihnen zukünftig helfen, schwerwiegende Sicherheitsvorfälle zu vermeiden.
