security.txt: der Meldeweg für Sicherheitshinweise
Hat deine Seite eine security.txt? Adresse eintragen, wir sehen nach.
Geprüft wird die ganze Seite, nicht nur dieser Punkt. Wir rufen sie ab wie jeder Besucher — es wird nichts verändert.
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.
Betrifft dich das? Prüf deine Website kostenlos — dauert 30 Sekunden, keine Anmeldung nötig.
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.txtEin 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. |
Alle Felder im Einzelnen
Der Standard kennt neun Felder. Zwei davon sind Pflicht, der Rest ist optional — und man muss nicht alle nutzen, um eine gute Datei zu haben.
| Feld | Pflicht | Wozu |
|---|---|---|
Contact | ja | Wohin gemeldet wird. E-Mail-Adresse oder Formular-URL, mehrere Zeilen erlaubt — die erste gilt als bevorzugt. |
Expires | ja | Ab wann die Angaben als veraltet gelten. Ohne dieses Feld ist die Datei nach dem Standard ungültig. |
Encryption | nein | Link auf einen öffentlichen Schlüssel, mit dem Meldungen verschlüsselt werden können. Der Schlüssel selbst gehört nicht in die Datei — nur die Adresse, unter der er liegt. |
Acknowledgments | nein | Seite, auf der du Findern dankst. Kostet nichts und motiviert, den Weg über dich statt über die Öffentlichkeit zu gehen. |
Preferred-Languages | nein | Sprachen, in denen gemeldet werden soll — als Kürzel, etwa de, en. Keine Rangfolge, nur eine Angabe. |
Canonical | nein | Die maßgebliche Adresse dieser Datei. Wichtig, wenn eine Organisation mehrere Domains hat: Sie zeigt, welche Datei die echte ist. |
Policy | nein | Link auf eure Regeln für Sicherheitsmeldungen — was erlaubt ist, was nicht, was Melder erwarten dürfen. |
Hiring | nein | Link auf Stellenangebote im Sicherheitsbereich. Klingt kurios, ist aber Teil des Standards. |
CSAF | nein | Verweis auf maschinenlesbare Sicherheitsmeldungen — relevant für Softwarehersteller, nicht für gewöhnliche Websites. |
Die Reihenfolge der Felder spielt keine Rolle. Kommentare sind erlaubt und beginnen mit
#.
Eine Minimalfassung, die reicht
Contact: mailto:security@deine-domain.de
Expires: 2027-08-01T00:00:00.000ZMehr braucht es nicht, um den Standard zu erfüllen. Alles Weitere ist Komfort.
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: Wer allein zuständig ist, ist irgendwann im Urlaub oder nicht mehr im Unternehmen.
- 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. Ein abgelaufenes Datum ist nach dem Standard dasselbe wie keine Datei — und wirkt schlechter, weil es zeigt, dass niemand mehr hinsieht. - Nicht länger als ein Jahr setzen. Der Standard empfiehlt das ausdrücklich. Ein Ablaufdatum im Jahr 2040 sagt: Diese Datei wird nie wieder angefasst.
- Das Datum im richtigen Format.
Expiresverlangt einen Zeitstempel nach RFC 3339, also etwa2027-08-01T00:00:00.000Z— nicht01.08.2027.
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.
Der alte Ort direkt unter /security.txt ist weiterhin als Rückfallposition zulässig,
/.well-known/security.txt ist aber der maßgebliche Pfad. Wer beides anbietet, sollte
dieselbe Datei ausliefern.
Wo es in der Praxis klemmt
| System | Typisches Problem | Lösung |
|---|---|---|
| WordPress mit Sicherheits-Plugin | Plugins sperren Verzeichnisse, die mit einem Punkt beginnen | Pfad /.well-known/ in den Plugin-Einstellungen ausnehmen |
| nginx | Eine Regel wie location ~ /\. blockiert alle Punkt-Pfade |
Vor dieser Regel einen eigenen location /.well-known/-Block einfügen |
| Next.js, Nuxt und ähnliche | Punkt-Ordner werden aus dem public-Verzeichnis nicht mit ausgeliefert |
Datei über eine Route ausliefern oder im Build ausdrücklich kopieren |
| Baukastensysteme | Kein Zugriff auf das Wurzelverzeichnis | Oft nicht lösbar — dann wenigstens eine gut auffindbare Sicherheitsseite verlinken |
| Beliebiger Server | Datei wird als text/html ausgeliefert |
MIME-Typ setzen: in Apache AddType text/plain .txt, in nginx über default_type |
Prüfen lässt sich beides in einem Befehl:
curl -sI https://deine-domain.de/.well-known/security.txt | head -3Erwartet werden 200 und Content-Type: text/plain. Kommt eine 404
oder ein HTML-Typ, ist die Datei nicht wirksam da.
Signieren — braucht man das?
Der Standard erlaubt es, die Datei mit OpenPGP zu signieren, damit niemand sie fälschen kann. Für die allermeisten Websites ist das übertrieben: Wer die Datei manipulieren könnte, hat ohnehin Zugriff auf den Server. Sinnvoll wird es für Organisationen, bei denen eine gefälschte Kontaktadresse echten Schaden anrichten könnte — etwa weil dort regelmäßig vertrauliche Schwachstellenmeldungen eingehen.
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.
Ein brauchbarer Ablauf, ohne Sicherheitsabteilung:
- Eingang bestätigen — ein Zweizeiler genügt, mit Datum und der Zusage, sich zu melden.
- Nachvollziehen, ob das Beschriebene zutrifft. Wenn nicht: freundlich zurückmelden, welche Schritte du versucht hast.
- Beheben und zurückmelden. Auch ein „wir haben es behoben, danke“ gehört dazu.
- Wenn du länger brauchst, sag es und nenne einen realistischen Zeitpunkt. Melder haben meist Verständnis für Termine, selten für Schweigen.
Zwei Dinge, die die Lage regelmäßig verschlechtern: mit rechtlichen Schritten zu drohen, und die Meldung als Werbung abzutun. Beides führt dazu, dass beim nächsten Fund niemand mehr schreibt.
Was du nicht hineinschreiben solltest
- keine persönlichen Adressen einzelner Mitarbeiter,
- keine Telefonnummern von Privatanschlüssen,
- keinen öffentlichen Schlüssel im Volltext — nur den Link darauf,
- keine Hinweise auf eingesetzte Software und Versionen. Die Datei ist ein Meldeweg, kein Inventarverzeichnis.
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.
Ist eine security.txt Pflicht?
Nein, sie ist freiwillig. Sie ist aber Teil vieler Sicherheitsfragebögen, die größere Auftraggeber vor einer Zusammenarbeit verschicken, und wird von Prüfwerkzeugen abgefragt. Der Aufwand liegt bei zehn Minuten.
Was passiert, wenn das Datum in Expires abgelaufen ist?
Dann gelten die Angaben nach dem Standard als veraltet — für Werkzeuge ist das gleichbedeutend mit einer fehlenden Datei. Und es wirkt schlechter als gar keine, weil es zeigt, dass niemand mehr hinsieht. Setz das Datum höchstens ein Jahr in die Zukunft und leg dir eine Erinnerung.
Muss der öffentliche Schlüssel in die Datei?
Nein — im Feld Encryption steht nur die Adresse, unter der der Schlüssel liegt. Der Schlüssel selbst gehört nicht in die Datei.
Meine security.txt wird als HTML ausgeliefert. Ist das ein Problem?
Ja. Der Standard verlangt text/plain. Prüfen lässt sich das mit curl -sI; ist der Content-Type falsch, hilft in Apache AddType text/plain .txt oder in nginx eine Anpassung von default_type.
Warum finde ich die Datei nicht, obwohl ich sie hochgeladen habe?
Häufigste Ursache sind Regeln, die Verzeichnisse mit einem Punkt am Anfang sperren — in Sicherheits-Plugins, in nginx (location ~ /\.) oder in JavaScript-Frameworks, die Punkt-Ordner nicht mit ausliefern. Der Pfad /.well-known/ muss ausdrücklich freigegeben werden.
Prüf deine Website in 30 Sekunden
Ein Scan pro Tag ist kostenlos — ohne Anmeldung, ohne Installation.
Stand: 6. August 2026. Dieser Text erklärt technische Zusammenhänge und ist keine Rechtsberatung.