security.txt: der Meldeweg für Sicherheitshinweise
Jemand findet ein Problem an deiner Website und möchte es dir melden. An wen schreibt er? Ohne klare Angabe landet der Hinweis im allgemeinen Kontaktformular, wird für Werbung gehalten und bleibt liegen. Genau dieses Problem löst eine kleine Textdatei.
Was das ist
Die security.txt ist in RFC 9116 beschrieben — dieselbe Art von Standard, die auch
E-Mail und HTTP definiert. Sie liegt an einer festen Adresse, sodass Sicherheitsforscher und automatische
Werkzeuge sie ohne Suchen finden:
https://deine-domain.de/.well-known/security.txt
Ein vollständiges Beispiel
Contact: mailto:security@deine-domain.de
Expires: 2027-08-01T00:00:00.000Z
Preferred-Languages: de, en
Canonical: https://deine-domain.de/.well-known/security.txt
Policy: https://deine-domain.de/security-policy.html
| Feld | Bedeutung |
|---|---|
Contact | Pflicht. E-Mail-Adresse oder Formular-URL. Mehrere Zeilen sind erlaubt. |
Expires | Pflicht. Ab wann die Angaben als veraltet gelten. |
Preferred-Languages | In welcher Sprache gemeldet werden soll. |
Canonical | Die maßgebliche Adresse dieser Datei. |
Policy | Link auf eure Regeln für Sicherheitsmeldungen. |
Encryption | Öffentlicher Schlüssel für verschlüsselte Meldungen. |
Worauf es ankommt
- Ein Postfach, das gelesen wird. Eine Adresse, die niemand prüft, ist schlimmer als keine Angabe — sie erzeugt den Anschein eines Meldewegs, der nicht existiert. Ein Verteiler an mehrere Personen ist besser als eine persönliche Adresse.
- Als Textdatei ausliefern. Der Server muss
text/plainsenden. Manche Systeme schicken stattdessen eine HTML-Fehlerseite mit Status 200 zurück — dann sieht es aus, als sei die Datei da, obwohl sie fehlt. - Ablaufdatum im Blick behalten. Ein Kalendereintrag zwei Wochen vor
Expiresgenügt.
Einrichten
Verzeichnis .well-known im Wurzelverzeichnis der Website anlegen, Datei
security.txt hineinlegen, im Browser aufrufen und prüfen, dass reiner Text erscheint
und keine gestaltete Seite. Bei WordPress kann ein Sicherheits-Plugin den Zugriff auf Verzeichnisse mit
Punkt am Anfang blockieren — dann muss dieser Pfad ausgenommen werden.
Wie verbreitet das ist: In unseren Messungen hatten rund 27 Prozent der sehr
großen Websites eine security.txt, aber nur etwa 5 Prozent der kleineren
Unternehmensseiten. Für kleine Anbieter ist es also noch ein Unterscheidungsmerkmal — besonders
gegenüber Kunden, die selbst einer Prüfpflicht unterliegen.
Und wenn tatsächlich eine Meldung kommt?
Kurz und sachlich antworten, auch wenn du das Problem noch nicht bewerten kannst. Ein Eingangs-Hinweis innerhalb weniger Tage verhindert die meisten Eskalationen. Wer wochenlang nicht reagiert, riskiert, dass der Finder sich an anderer Stelle meldet.
Häufige Fragen
Ist eine security.txt Pflicht?
Nein, es gibt keine allgemeine gesetzliche Pflicht. Sie ist eine Erwartung im Umfeld von NIS2, ISO 27001 und dem Cyber Resilience Act und taucht zunehmend in Ausschreibungen und Lieferantenfragebögen auf.
Wo genau muss die Datei liegen?
Unter /.well-known/security.txt. Der zusätzliche Ablageort direkt im Wurzelverzeichnis ist nur noch aus Kompatibilitätsgründen vorgesehen.
Was, wenn ich dann mit Meldungen überschwemmt werde?
In der Praxis kommen vor allem automatisierte Massenhinweise von Leuten, die auf eine Belohnung hoffen. Wer keine Belohnung zahlt, schreibt das in die Policy-Datei — das reduziert solche Zuschriften deutlich.
Muss ich das Ablaufdatum wirklich pflegen?
Ja, das Feld Expires ist verpflichtend. Läuft es ab, gilt die Datei als veraltet. Üblich ist ein Jahr, mit einem Kalendereintrag für die Verlängerung.
Prüf deine Website in 30 Sekunden
Ein Scan pro Tag ist kostenlos — ohne Anmeldung, ohne Installation.
Stand: 1. August 2026. Dieser Text erklärt technische Zusammenhänge und ist keine Rechtsberatung.