Security: Warum das BSI jetzt eine winzige Textdatei für jede Website empfiehlt

Kategorien: Datenschutz

Nur 1,8 Prozent aller deutschen Websites verraten Angreifern und Sicherheitsforschern gleichermaßen, wen sie im Ernstfall kontaktieren sollen. Eine einzige Textdatei würde reichen, um das zu ändern – und das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt sie inzwischen ausdrücklich.

Warum eine simple Textdatei plötzlich Aufmerksamkeit bekommt

Stellen Sie sich vor, eine unabhängige Sicherheitsforscherin entdeckt zufällig eine Schwachstelle auf Ihrer Website. Sie möchte diese verantwortungsvoll melden, bevor sie in falsche Hände gerät. Doch wohin? Ein Blick ins Impressum hilft selten weiter, die allgemeine Support-Adresse ist oft der falsche Ansprechpartner, und wertvolle Zeit verstreicht, während die Lücke offen bleibt.

Genau dieses Problem löst die sogenannte security.txt. Es handelt sich um eine standardisierte, maschinenlesbare Textdatei, die auf jeder Website an einer festen, vorhersehbaren Stelle hinterlegt werden kann. Sie beantwortet in Sekunden die Frage, die im Ernstfall zählt: Wer ist zuständig, und wie erreiche ich diese Person sicher?

Was nach einer Nischen-Empfehlung für große Konzerne klingt, hat inzwischen behördliches Gewicht bekommen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) rief am 6. August 2026 gemeinsam mit der Allianz für Cyber-Sicherheit (ACS) dazu auf, die security.txt flächendeckend einzuführen. Der Anlass: Messungen im Rahmen des BSI-Projekts Cyberdome zeigten, dass gerade einmal 1,8 Prozent der deutschen Webseitenbetreiber diese Datei bislang bereitstellen, obwohl der Aufwand denkbar gering ist.

Der Zweck: ein verlässlicher Meldeweg statt Zufall

Die security.txt ist keine Erfindung des BSI, sondern ein internationaler technischer Standard, festgelegt im RFC 9116 der Internet Engineering Task Force (IETF). Der Kerngedanke ist einfach: Statt dass jede Organisation ihren eigenen, oft schwer auffindbaren Meldeweg für Sicherheitslücken erfindet, folgt sie einem gemeinsamen Format an einem gemeinsamen Ort.

Ohne diesen Standard passiert in der Praxis regelmäßig eines von drei Dingen:

• Die Meldung erreicht niemanden, weil kein offizieller Kontakt existiert.
• Sie landet bei der falschen Abteilung und verzögert sich unnötig.
• Sicherheitsforscher geben entnervt auf und veröffentlichen die Lücke öffentlich, bevor sie behoben ist – mit allen Risiken, die das für Besucher und Kunden der Website mit sich bringt.

Eine korrekt eingerichtete security.txt verhindert genau das. Sie schafft einen eindeutigen, dokumentierten Kanal für sogenannte Coordinated Vulnerability Disclosure – die koordinierte, verantwortungsvolle Offenlegung von Schwachstellen, bei der Betreiber Zeit zur Behebung bekommen, bevor Details öffentlich werden.

Was konkret in der Datei steht

Die security.txt liegt technisch immer unter dem festen Pfad https://ihre-domain.de/.well-known/security.txt und besteht aus einfachen Textzeilen. Zwei davon sind laut RFC 9116 verpflichtend:

• Contact – gibt an, wie Sicherheitsexperten Sie erreichen können, meist per E-Mail-Adresse, manchmal ergänzt um Telefonnummer oder Kontaktformular.
• Expires – ein Ablaufdatum, das signalisiert, bis wann die Angaben als aktuell gelten. Das zwingt Betreiber indirekt dazu, die Datei regelmäßig zu pflegen, statt sie einmal anzulegen und zu vergessen.

Darüber hinaus gibt es mehrere empfohlene und optionale Felder, die den Nutzen erheblich steigern können: einen Link zur eigenen Vulnerability-Disclosure-Policy, einen PGP-Schlüssel für verschlüsselte Meldungen, eine Hall-of-Fame-Seite für Sicherheitsforschende oder auch bevorzugte Sprachen für die Kommunikation. Die Datei kann zudem digital signiert werden, um ihre Echtheit zusätzlich abzusichern.

So richten Sie die Datei in wenigen Minuten ein

Die technische Umsetzung ist bewusst niedrigschwellig gehalten. Eine minimale, gültige security.txt besteht aus nur zwei Zeilen:

Contact: mailto:security@ihre-domain.de
Expires: 2027-08-25T00:00:00Z

Diese Datei speichern Sie als reine Textdatei und laden sie unter dem Pfad /.well-known/security.txt auf Ihren Webserver – bei den meisten Hosting-Umgebungen reicht dafür ein gewöhnlicher FTP- oder Datei-Manager-Zugriff. Ein eigenes Content-Management-System oder eine Programmierkenntnis ist dafür nicht erforderlich.

Wichtig ist dabei die korrekte Auslieferung durch den Webserver: Die Datei sollte als text/plain mit der Kodierung UTF-8 ausgeliefert werden. Bei den meisten Standard-Konfigurationen ist das bereits automatisch der Fall, sofern die Datei lediglich als .txt-Datei gespeichert wurde. Wer zusätzlich Wert auf Sorgfalt legt, ergänzt einen Link zur eigenen Vulnerability-Disclosure-Policy und setzt das Ablaufdatum realistisch – üblich sind sechs bis zwölf Monate in der Zukunft, damit die Datei tatsächlich regelmäßig überprüft und aktualisiert wird, statt einmal angelegt und dann vergessen zu werden.

Warum das gerade jetzt an Bedeutung gewinnt

Die security.txt ist längst nicht mehr nur eine freiwillige Fleißaufgabe. Der Cyber Resilience Act (CRA) der EU stellt verbindliche Anforderungen an den Umgang mit Schwachstellenmeldungen und wird ab Dezember 2027 vollständig verpflichtend. Bereits ab dem 11. September 2026 gelten zudem Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle. Wer bereits jetzt einen funktionierenden Meldeweg etabliert, verschafft sich einen komfortablen Vorsprung bei der Umsetzung dieser regulatorischen Vorgaben, statt später unter Zeitdruck nachzurüsten.

Das BSI betont in seiner Mitteilung außerdem den geringen Aufwand im Verhältnis zum Nutzen. Wer die beiden Pflichtfelder korrekt setzt und die Datei am richtigen Pfad bereitstellt, hat die wichtigsten Anforderungen bereits erfüllt – eine der niedrigschwelligsten IT-Sicherheitsmaßnahmen überhaupt, wie es in der Pressemitteilung heißt.

In der Praxis zeigt sich allerdings, dass gerade bei der Umsetzung häufig kleine, aber folgenreiche Fehler passieren: ein falscher HTTP-Content-Type, ein zu weit in der Zukunft liegendes Ablaufdatum, das die eigentliche Pflege konterkariert, oder eine Datei, die zwar existiert, aber unter dem falschen Pfad liegt und dadurch von automatisierten Prüfungen schlicht nicht gefunden wird. Genau solche Details lassen sich mit einem automatisierten Security Check zuverlässig aufdecken – der neben dem reinen Vorhandensein auch den strukturellen Aufbau der security.txt nach RFC 9116 prüft und bei jedem gefundenen Problem eine verständliche, konkrete Hilfestellung liefert, wie es korrekt aussehen sollte.

Beispiele für Hilfestellungen sind im nächsten Abschnitt gegeben. Die Hilfeseiten des eben genannten Web Security Checks sind noch umfangreicher und enthalten anschauliche Beispiele für Webmaster.

Technische Hinweise zur Umsetzung

Über die reine Feldsyntax hinaus gibt es einige technische Details, die in der Praxis häufig übersehen werden, sich aber deutlich auf die korrekte Funktion der security.txt auswirken.

Die Datei muss über das verschlüsselte Protokoll HTTPS abrufbar sein – ein Abruf über unverschlüsseltes HTTP gilt nach RFC 9116 als nicht konform, da sich der Inhalt sonst auf dem Übertragungsweg manipulieren ließe. Zusätzlich empfiehlt die Spezifikation, die Datei kompakt zu halten: Richtwerte sind eine Gesamtgröße unter 32 Kilobyte, einzelne Feldwerte unter 2.048 Zeichen und insgesamt unter 1.000 Zeilen. Das erleichtert automatisierten Auswertungswerkzeugen die zuverlässige Verarbeitung.

Wer die Datei über Apache betreibt, kann Content-Type und eine Weiterleitung vom veralteten Wurzelverzeichnis-Pfad zentral über die .htaccess-Datei steuern:

AddType text/plain .txt
Redirect 301 /security.txt /.well-known/security.txt

Damit ist sichergestellt, dass sowohl der korrekte, verbindliche Pfad unter /.well-known/ als auch ein möglicher Altpfad im Wurzelverzeichnis auf dasselbe Ziel verweisen. Existieren beide Varianten gleichzeitig mit unterschiedlichem Inhalt, gilt laut Standard stets die Version unter /.well-known/ als maßgeblich.

Ein häufiger Stolperstein: HTTP-Response-Header wie Content-Type gehören ausschließlich in die Server-Konfiguration, nicht als eigene Zeile in den Dateiinhalt selbst. Eine Zeile wie „Content-Type: text/plain; charset=utf-8" innerhalb der security.txt ist kein gültiges Feld nach RFC 9116 und wird von auswertenden Systemen schlicht ignoriert. Auch der Geltungsbereich verdient Beachtung: Eine security.txt gilt ausschließlich für exakt die Domain oder Subdomain, unter der sie abgerufen wurde – shop.ihre-domain.de benötigt bei Bedarf eine eigene Datei, unabhängig von der auf ihre-domain.de hinterlegten Version.

Wer zusätzliche Vertrauenswürdigkeit signalisieren möchte, kann die gesamte Datei per OpenPGP digital signieren. Das ist keine eigene Zeile, sondern eine kryptografische Hülle um den kompletten Inhalt, die belegt, dass die Datei tatsächlich vom Domaininhaber stammt und nicht nachträglich verändert wurde. In diesem Fall wird zusätzlich ein Canonical-Feld empfohlen, damit auch der offizielle Speicherort der Datei durch die Signatur mit abgesichert ist.

Fazit: kleiner Aufwand, spürbarer Unterschied

Die security.txt ist eines der seltenen Beispiele, bei denen wenige Minuten Arbeit einen echten Unterschied für die Sicherheit einer Website machen können. Sie kostet keine Lizenzgebühr, erfordert keine neue Infrastruktur und lässt sich mit einem einfachen Texteditor umsetzen. Gleichzeitig signalisiert sie nach außen, dass eine Organisation Sicherheitsthemen ernst nimmt und Meldungen willkommen heißt, statt sie zu erschweren.

Wer schreibt hier?

Mein Name ist Klaus Meffert. Ich bin promovierter Informatiker und beschäftige mich seit über 30 Jahren professionell und praxisbezogen mit Informationstechnologie. In IT & Datenschutz bin ich auch als Sachverständiger tätig. Ich stehe für pragmatische Lösungen mit Mehrwert. Meine Firma, die IT Logic GmbH, berät Kunden und bietet Webseiten-Checks sowie optimierte & sichere Lösungen an (mit und ohne KI).