An deiner Webseite fehlt die Klingel

Gestern Abend habe ich https://www.chrislo.de/.well-known/security.txt in die Adresszeile getippt und eine Fehlerseite bekommen. 404, nichts da. Auf der Seite einer IT-Beraterin, deren halbe Arbeit aus IT-Sicherheit besteht.

Anlass war eine Meldung des Bundesamts für Sicherheit in der Informationstechnik vom Donnerstag, dem 6. August. Nach einer Messung des BSI im Projekt Cyberdome haben rund 1,8 Prozent der deutschen Webseitenbetreiber eine solche Datei. Eine veröffentlichte Studie steht dahinter nicht, das BSI nennt weder Stichprobe noch Methode, und die heise-Meldung vom selben Tag referiert nur die Pressemitteilung. Als Größenordnung reicht die Zahl: Bei 98 von hundert deutschen Webseiten muss jemand, der eine Sicherheitslücke gefunden hat, raten, wohin er sie meldet.

Heute früh war ich dann eine der zwei Prozent. Bei einer statisch gebauten Seite wie meiner ist das eine Sache von Minuten. Die Datei kommt in den Ordner public/.well-known/, und alles, was dort liegt, landet unverändert in der fertigen Seite. Der komplette Inhalt:

# security.txt für www.chrislo.de
# Format: RFC 9116

Contact: mailto:security@chrislo.de
Expires: 2027-08-01T00:00:00.000Z
Canonical: https://www.chrislo.de/.well-known/security.txt
Policy: https://www.chrislo.de/security-policy
Preferred-Languages: de

Und weil du sonst denkst, so etwas ginge immer glatt: Beim ersten Versuch stand in der zweiten Kommentarzeile ein Link auf das Standarddokument. Der Build meiner Seite prüft automatisch, dass keine externen Adressen im fertigen Ergebnis landen, und ist an genau dieser Zeile ausgestiegen. Der Link musste wieder raus. Zehn Minuten, großzügig gerechnet, inklusive Fluchen.

Sieben Zeilen, an die niemand denkt

Stell dir vor, jemand sieht auf dem Heimweg, dass an deinem Haus ein Kellerfenster offen steht. Die Person will klingeln. Es gibt keine Klingel, keinen Namen am Schild, keinen Briefkasten. Also geht sie weiter. Das Fenster bleibt offen, du erfährst es nie, und irgendwann steht jemand anderes davor, der nicht klingeln wollte.

Genau diese Klingel ist die security.txt. Eine schlichte Textdatei auf deinem Webserver, in der steht, an wen man sich wendet, wenn man in deiner Webseite eine Sicherheitslücke gefunden hat. Kein Programm, kein Dienst, keine laufenden Kosten. Text. Das Format ist seit April 2022 als RFC 9116 festgeschrieben, als öffentliches Standarddokument derselben Gruppe, die auch festlegt, wie E-Mail funktioniert. Folgt eine Datei diesem Standard, kann jedes Programm sie lesen, ohne zu raten.

Und jetzt die Frage, die du an dieser Stelle zu Recht stellst: In deinem Impressum steht doch eine E-Mail-Adresse, nach Paragraf 5 des Digitale-Dienste-Gesetzes muss sie sogar dort stehen. Stimmt. Nur liest die keine Maschine. Was ein Programm in deinem Impressum vorfindet, ist Fließtext für Menschen: Anschrift, Registergericht, Umsatzsteuer-Identifikationsnummer und irgendwo dazwischen eine Mailadresse, von der es nicht weiß, ob dahinter der Vorstand, die Buchhaltung oder ein Kontaktformular sitzt. Die security.txt liegt bei jeder Webseite der Welt am selben Ort und sagt dasselbe in derselben Form.

Was passiert, wenn dieser eindeutige Kontakt fehlt, schreibt das BSI in seiner FAQ für Hersteller selbst: Findet es keinen erkennbaren Sicherheitskontakt, weicht es auf die Datenschutz- oder die Info-Adresse aus. Wer schon einmal in das info@-Postfach eines Vereins geschaut hat, weiß, was das heißt. Zwischen Rückfragen zum Sommerfest, Newslettern und Spam liegt dann eine Mail einer Bundesbehörde, in der steht, dass an eurer Webseite etwas offen ist. Gelesen wird sie, wenn jemand Zeit hat.

Bei den 98 Prozent fehlt also nicht die Adresse. Es fehlt die Klingel an der Stelle, an der eine Maschine nachschaut.

Die Datei ist in zehn Minuten geschrieben. Länger dauert die Frage dahinter: Wer liest die Mail, und was tut diese Person dann? Damit fange ich an, nicht mit dem Dateiinhalt.

Schritt 1: Entscheide, wer die Meldung bekommen soll

Das niederländische NCSC, die Cybersicherheitsbehörde des dortigen Justiz- und Sicherheitsministeriums, hat eine achtstufige Anleitung zur security.txt veröffentlicht, und sie beginnt nicht mit Technik. Schritt eins ist die Frage, wer die Meldung bekommen soll: die Organisation selbst oder der IT-Dienstleister, der die Webseite betreut. Maßstab ist nicht, wer im Impressum steht, sondern wer mit einer Meldung etwas anfangen kann. Bei einer Vereinsseite, die vor vier Jahren ein befreundeter Grafiker aufgesetzt hat, liest die Vorsitzende die Mail zwar, braucht aber jemanden, an den sie sie weiterreicht. Diese Absprache triffst du vorher, nicht in dem Moment, in dem die Mail ankommt.

Und nimm eine Funktionsadresse, keine persönliche. Das BSI empfiehlt in seiner FAQ für Hersteller ausdrücklich security@deine-domain.de oder cert@deine-domain.de. Eine Adresse wie vorname@ läuft ins Leere, sobald die Person Urlaub hat, krank wird oder den Verein verlässt. Eine Weiterleitung auf ein bestehendes Postfach kostet bei jedem Hoster nichts.

Schritt 2: Schreib die Datei

Für einen Verein sieht sie so aus. Das ist der komplette Inhalt, ersetzt werden nur die Domain und die Adressen:

# Sicherheitskontakt des Musterverein e. V.
# Meldungen zu Sicherheitsluecken bitte an die unten genannte Adresse.

Contact: mailto:sicherheit@musterverein.de
Contact: tel:+49-30-12345678
Expires: 2027-08-01T12:00:00Z
Preferred-Languages: de, en
Policy: https://www.musterverein.de/sicherheitsmeldungen

Für eine Einzelunternehmerin reichen vier Zeilen:

# Sicherheitskontakt
Contact: mailto:security@beispiel-design.de
Expires: 2027-08-01T12:00:00Z
Preferred-Languages: de, en

Zeilen mit # am Anfang sind Kommentare für menschliche Leser*innen, Programme ignorieren sie. Umlaute sind dort erlaubt, in den Feldwerten darunter besser nicht.

Pflicht sind genau zwei Felder, alles andere ist Zugabe. Contact sagt, wohin die Meldung geht, Expires sagt, bis wann die Angabe gilt. Das mailto: vor der Adresse ist keine Zierde, sondern Teil des Standards, ohne dieses Vorwort ist die Datei ungültig. Mehrere Contact-Zeilen sind erlaubt, und die Reihenfolge bedeutet Vorrang. Deshalb steht die Telefonnummer unten, denn so eine Meldung bekommt ein Verein lieber schriftlich, und wer keine Nummer veröffentlichen will, lässt die Zeile weg. Preferred-Languages fehlt in vielen Vorlagen, und das ist ein Fehler: Ohne dieses Feld nimmt der Standard stillschweigend Englisch an.

Was du nicht übernehmen solltest, obwohl es in meiner eigenen Datei oben steht: das Feld Canonical. Es trägt die Adresse ein, unter der die Datei liegt, und klingt harmlos. Der Standard sagt aber, dass eine Datei als nicht vertrauenswürdig gilt, sobald sie über eine Adresse abgerufen wird, die dort nicht steht. Läuft deine Seite unter verein.de und unter www.verein.de und du trägst nur eine davon ein, entwertest du deine eigene Datei für jeden, der die andere aufruft. Bei mir passt es, weil chrislo.de per Weiterleitung immer auf www.chrislo.de landet und ich das weiß. Wenn du es nicht weißt, lass das Feld weg.

Beim Feld Policy gilt das Umgekehrte: Trage es ein, wenn die Seite dahinter wirklich existiert. Bei mir zeigt die Zeile inzwischen auf https://www.chrislo.de/security-policy. Dort steht, welche Meldungen ich mir wünsche, was ausdrücklich nicht in Ordnung ist, wie ich mit Hinweisen umgehe und dass ich bei gutgläubigen Meldungen innerhalb dieser Regeln keine rechtlichen Schritte einleite. Ein Link ins Leere macht die Datei schlechter als gar kein Feld, deshalb gehört die Zeile erst hinein, wenn die Policy-Seite steht. Warum sich diese Seite gerade für deutsche Organisationen lohnt, steht weiter unten, und es ist der wichtigste Absatz dieses Artikels.

Schritt 3: Leg sie an die richtige Stelle

Die Datei gehört nach /.well-known/security.txt. Der Ordner .well-known ist ein reservierter Ort, den es auf Webservern für genau solche Standarddateien gibt, ähnlich wie ein Hausbriefkasten immer an der Straße hängt und nicht im Wohnzimmer. Sein Name beginnt mit einem Punkt, weil solche Ordner unter Linux als Systemkram gelten und in Dateimanagern standardmäßig ausgeblendet werden. Merk dir das, es wird gleich wichtig. Das BSI stellt in seinem älteren Papier BSI-CS 149 diesen Ort und die Ablage direkt im Wurzelverzeichnis gleichrangig nebeneinander, der Standard tut das nicht. Nimm /.well-known/, dann hast du keine Diskussion.

Wie du dort hinkommst, hängt an einer einzigen Frage: Kommst du überhaupt an die Dateien deiner Webseite heran?

Bei WordPress musst du das gar nicht. Eine Erweiterung erledigt die Sache im Browser, ohne dass du eine Datei anfasst. Mir gefällt „Generate Security.txt“ am besten, herausgegeben vom niederländischen Registrar-Verband, kostenlos und ohne Bezahlversion, zuletzt aktualisiert am 29. Juni 2026. Dahinter steht keine US-Firma.

Bei klassischem Webspace lädst du die Datei selbst hoch, und da wartet der Punkt-Stolperstein: Du legst den Ordner an, dein Programm blendet ihn aus, du legst ihn noch einmal an. STRATO beschreibt den Ausweg in seiner FAQ zum SFTP-Zugang so klar wie kein anderer deutscher Hoster. In FileZilla unter „Server“ die Option „Auflistung versteckter Dateien erzwingen“ aktivieren, und wenn der Ordner dann immer noch fehlt, unter „Ansicht“ im Datei- und Verzeichnisfilter den Filter „Configuration files“ abschalten. IONOS dokumentiert einen zweiten Weg, der ohne FTP-Programm auskommt: Ordner samt Datei auf dem eigenen Rechner anlegen, in ein ZIP-Archiv packen, das im Webspace Explorer hochladen und dort entpacken. Der Ordnername steckt dann im Archiv und muss nirgends eingetippt werden. Einer dieser beiden Wege funktioniert bei praktisch jedem Webspace.

Und jetzt die unangenehme Antwort für alle mit einem Baukasten: Bei Wix und bei Jimdo geht es nicht. Wix stellt genau eine Datei im Wurzelverzeichnis zur Bearbeitung, die robots.txt über das SEO-Dashboard, zur security.txt steht in der Hilfe nichts. Ein zitierbares Verbot gibt es nicht, aber Wix sieht dafür schlicht keinen Weg vor. Jimdo bietet nach allem, was sich nachvollziehen lässt, keinen Dateizugriff auf das Wurzelverzeichnis, wobei das Jimdo-Hilfe-Center am 7. August nicht abrufbar war und ich deshalb nichts im Wortlaut behaupte. Bei WordPress.com lassen sich Erweiterungen ab dem günstigsten Bezahltarif installieren, auf einer kostenlosen Seite nicht.

Bleibt dein Baukasten stur, bleibt nur eine organisatorische Lösung: eine klar benannte Zeile mit einem Sicherheitskontakt auf der Kontaktseite, damit wenigstens ein Mensch nicht raten muss, auch wenn eine Maschine weiter im Dunkeln tappt. Wirklich lösen lässt sich das nur mit einem Umzug auf einen Hoster mit echtem Webspace.

Schritt 4: Prüf nach, ob es geklappt hat

Tipp https://deine-domain.de/.well-known/security.txt in die Adresszeile, einmal mit www. und einmal ohne. Erscheint der Text im Fenster, bist du fertig. Erscheint eine Fehlerseite, liegt die Datei nicht dort, wo du denkst, oder der Ordnername hat einen Tippfehler.

Der dritte Fall führt Leute reihenweise in die Irre: Der Browser bietet dir einen Download an, statt den Text zu zeigen. Dann liegt die Datei richtig, aber dein Server klebt ihr das falsche Etikett auf. Jede Datei bekommt beim Ausliefern einen sogenannten Content-Type mit, eine Angabe darüber, was drin ist, und der Standard verlangt hier text/plain mit charset=utf-8, also schlichten Text. Manche Server behandeln alle .txt-Dateien pauschal als Download, und das muss dein Hoster ändern.

Wer sich ans Terminal traut, also an das Textfenster, in dem man Befehle eintippt statt zu klicken, sieht beides auf einen Schlag:

curl -i https://deine-domain.de/.well-known/security.txt

Das -i zeigt die Kopfzeilen mit an, und darin müssen eine Zeile mit 200 und eine Zeile content-type: text/plain; charset=utf-8 stehen.

Schritt 5: Trag dir das Ablaufdatum in den Kalender

Das ist der Schritt, den alle überspringen, und der einzige, der später wehtut.

Expires sagt einer meldenden Person, ob die Adresse noch stimmt. Der Standard empfiehlt ein Datum weniger als ein Jahr in der Zukunft, das BSI empfiehlt dasselbe. Läuft es ab, gelten die Angaben als nicht mehr verlässlich. Deshalb steht in meinen Vorlagen der 1. August 2027: knapp unter einem Jahr, und ein rundes Datum findet man im Kalender leichter wieder als ein krummes.

Wie leicht dieser Schritt untergeht, zeigen ausgerechnet die beiden Seiten, die es besser wissen müssten, beide am 7. August selbst abgerufen. Die security.txt von securitytxt.org, der Referenzseite des Standards, betrieben von den Autoren des RFC, ist seit dem 27. März 2026 abgelaufen. Und das BSI, das gerade allen anderen die Datei ans Herz legt, hat in seiner eigenen ein Ablaufdatum im Jahr 2099 eingetragen, 73 Jahre in der Zukunft, im Widerspruch zur eigenen Empfehlung. Dieselbe Datei sitzt nebenbei in der Canonical-Falle von oben. Das mit einem Augenzwinkern, nicht als Verriss. Ein Kalendereintrag für Ende Juli 2027 mit dem Text „security.txt verlängern“ ist die billigste Versicherung dieses Artikels.

Wenn die Behörde zum Selbermachen rät und der Weg über Google führt

Das BSI empfiehlt in seinem Flyer vom 6. August wörtlich, https://www.securitytxt.org helfe beim Erstellen. In BSI-CS 149 nennt es zusätzlich findsecuritycontacts.com und internet.nl. Ich habe mir alle drei am 7. August angesehen.

securitytxt.org wird über GitHub Pages ausgeliefert und läuft hinter Cloudflare, beides US-Unternehmen. Die Seite lädt Schriften von Google, ein Stylesheet von einem Cloudflare-Verteilnetz, Bilder von GitHub und bindet ein YouTube-Video ein. Wer der Empfehlung des BSI folgt, baut für sieben Zeilen Text Verbindungen zu drei US-Konzernen auf. findsecuritycontacts.com liegt auf Amazon Web Services. Fair bleiben, wo Fairness angebracht ist: Der Generator auf securitytxt.org arbeitet ausschließlich im Browser, ich habe das Skript durchgesehen, es sendet nichts nach draußen. Deine Adresse verlässt deinen Rechner nicht. Mich stört der Aufruf der Seite, nicht der Generator.

Bleibt internet.nl, und das ist das interessante Werkzeug. Es prüft die security.txt tatsächlich mit, betrieben wird es vom Dutch Internet Standards Platform unter Beteiligung der niederländischen Regierung, das dortige NCSC verweist selbst darauf, gehostet wird es in den Niederlanden bei Prolocation, für die Zugriffsstatistik läuft ein selbst betriebenes Matomo. Im neuen BSI-Flyer taucht es nicht auf, nur im älteren Papier von 2024. Einen Haken hat auch internet.nl, und ich nenne ihn, weil ich dir nicht ein US-Problem gegen ein niederländisches eintauschen will: Der Test läuft auf deren Server, deine Domain wird gespeichert und kann laut Datenschutzerklärung in der öffentlichen Hall of Fame auftauchen. Wenn du das nicht willst, nimm Browser und curl. Für zwei Pflichtfelder brauchst du kein Werkzeug von irgendjemandem.

Der Cyber Resilience Act zwingt dich zu gar nichts

Die BSI-Pressemitteilung richtet sich an „Webseitenbetreiber“ und schreibt zwei Absätze weiter, ab dem 11. September 2026 gälten Meldepflichten für aktiv ausgenutzte Schwachstellen, weshalb sich die Umsetzung der security.txt lohne. Formal falsch ist der Satz nicht. Wer ihn schnell liest, nimmt aber mit, dass er im September etwas muss.

Muss er nicht. Erwägungsgrund 12 der Cyberresilienz-Verordnung nimmt Webseiten ausdrücklich aus dem Anwendungsbereich aus, sofern sie nicht die Funktion eines Produkts mit digitalen Elementen unterstützen. Der Artikel, um den es beim 11. September geht, heißt im amtlichen Titel „Meldepflichten der Hersteller“. Auch der BSI-Flyer formuliert präziser als die eigene Pressemitteilung, dort steht „für Hersteller von Produkten mit digitalen Elementen“. Ein Verein mit einer Webseite ist am 11. September 2026 zu nichts verpflichtet.

Wen es trifft, habe ich in „Dein Router bekommt ein Mindesthaltbarkeitsdatum“ beschrieben: Wer eine App herausgibt, ein Gerät verkauft oder Software vertreibt, ist Hersteller im Sinne der Verordnung. Für alle anderen gilt: Du legst die Datei an, weil sie sinnvoll ist, nicht weil Brüssel es verlangt.

Der Grund, warum in Deutschland kaum jemand meldet

Und jetzt der Teil, der mich wirklich ärgert.

Ein Softwareentwickler entdeckte bei einem Gladbecker IT-Dienstleister namens Modern Solution eine Sicherheitslücke und wies darauf hin. Das Amtsgericht Jülich verurteilte ihn im Januar 2024 zu einer Geldstrafe wegen Ausspähens von Daten nach Paragraf 202a des Strafgesetzbuchs. Das Landgericht Aachen verwarf die Berufung im November 2024, das Oberlandesgericht Köln lehnte die Revision im Juli 2025 ab, und am 15. September 2025 nahm das Bundesverfassungsgericht die Verfassungsbeschwerde ohne Begründung nicht zur Entscheidung an. Verurteilt, rechtskräftig, für eine gemeldete Lücke.

Die versprochene Reform des Computerstrafrechts liegt seitdem auf Eis. Ein Referentenentwurf des Bundesjustizministeriums vom 4. November 2024 hätte das Suchen nach Schwachstellen straffrei gestellt, wenn die Absicht besteht, die zuständige Stelle zu informieren. Der Bundestag hat ihn nicht mehr verabschiedet, mit dem Ende der Wahlperiode war er erledigt. Am 4. November 2025 sagte eine Sprecherin des Ministeriums gegenüber heise online, man nehme den Auftrag ernst und prüfe, wie er umzusetzen sei. Einen Zeitplan gab es nicht, und Stand August 2026 liegt kein neuer Gesetzentwurf vor. BSI-Präsidentin Claudia Plattner wurde in derselben Meldung deutlich: Wenn jemand zu ihr komme und sage, in ihrer Software sei ein Problem, dann gehöre diese Person nicht verfolgt, dann müsse man einfach Danke sagen.

Solange das so ist, überlegt sich jede Person, die auf deiner Vereinsseite zufällig eine offene Datenbank findet, sehr genau, ob sie dich anschreibt. Das Risiko trägt sie, den Schaden trägst du.

Deshalb halte ich das Feld Policy für kleine Organisationen für mehr als ein Etikett, und das ist meine Einschätzung, keine Aussage der Quellen. Eine Seite mit zwei Sätzen reicht: Wir freuen uns über Hinweise auf Sicherheitslücken, und wer uns eine Lücke meldet und uns vor einer Veröffentlichung Zeit gibt, hat von uns keine rechtlichen Schritte zu befürchten. Zehn Minuten Arbeit, und genau die Hürde ist weg, die den Meldeweg sonst blockiert. Was so eine Seite nicht kann, und ich verspreche hier nichts: Sie ist keine rechtlich bindende Zusage und schützt niemanden vor der Staatsanwaltschaft, weil Paragraf 202a nicht nur auf Antrag verfolgt wird. Sie senkt die Hemmschwelle, mehr leistet sie nicht. Und mehr, als die 98 von hundert Webseiten ohne diese Datei im Moment aussenden, ist das immer noch.

Und dann kommt die Mail. Was jetzt?

Irgendwann liegt sie im Postfach. Jemand schreibt, dass an deiner Seite etwas offen steht.

Das BSI beschreibt den Ablauf in seiner FAQ für Hersteller konkreter, als ich erwartet hatte: Meldung an die verantwortliche Stelle weiterleiten, Erhalt innerhalb von drei Werktagen bestätigen. Formal gilt diese Frist für Rückmeldungen an das BSI, wenn das BSI die Meldung vermittelt hat, als Orientierung taugt sie trotzdem, weil sie die einzige konkrete Zahl ist, die eine deutsche Behörde hier nennt. Drei Werktage für ein „Danke, angekommen, wir kümmern uns“. Mehr ist im ersten Schritt nicht verlangt.

Das niederländische NCSC stellt in Schritt 7 seiner Anleitung die Frage, die über den ganzen Aufwand entscheidet: Weiß die Person, die die Meldungen bekommt, was damit zu tun ist? Das BSI schreibt in BSI-CS 149 dasselbe, es müsse innerhalb der Organisation Prozesse geben, wie mit eingehenden Meldungen umgegangen wird. Für einen Verein reicht dafür ein Satz im Vorstandsprotokoll: Meldungen an die Sicherheitsadresse gehen an Person X, und die ruft im Ernstfall bei Dienstleister Y an.

Bleibt die Angst, die ich in Beratungen am häufigsten höre: dass es peinlich aussehe, wenn öffentlich wird, dass die Vereinsseite ein Problem hatte. Das BSI beantwortet genau diese Frage in seiner FAQ mit einem Wort und einem Satz. „Nein. Der offene Umgang mit Schwachstellen stellt vielmehr ein Qualitätsmerkmal dar.“

Peinlich wird es erst, wenn jemand drei Wochen lang versucht hat, dich zu erreichen, und keine Klingel gefunden hat.

Zehn Minuten, und du bist unter den zwei Prozent

Mach es heute. Entscheide, wer die Mail lesen soll. Richte security@ als Weiterleitung ein. Schreib die vier Zeilen aus der zweiten Vorlage in eine Textdatei. Leg sie unter /.well-known/ ab, ruf die Adresse im Browser auf, und trag dir Ende Juli 2027 eine Erinnerung ein. Das war es.

Wenn dein Baukasten dich ausbremst, wenn du nicht weißt, wo bei deinem Hoster das Wurzelverzeichnis liegt, oder wenn dir bei der Frage „und wer kümmert sich dann eigentlich um die Meldung“ die ehrliche Antwort fehlt: Genau an solchen Stellen setze ich an. Ich richte Vereinen und kleinen Firmen den Meldeweg ein, prüfe die Datei gegen den Standard, kläre mit dem Hoster den Content-Type und schreibe die zwei Sätze, die auf die Policy-Seite gehören. Meistens ist das eine Stunde Arbeit, kein Projekt.

Reden wir über deinen Meldeweg.

Schreib mir eine E-Mail: Kurz beschreiben, was du vorhast oder was dich beschäftigt. Ich melde mich in der Regel innerhalb eines Werktages. hallo@chrislo.de

Kein Kontaktformular, keine Pflichtfelder, keine Datenspur. Einfach schreiben.