security.txt erstellen

Eine security.txt sagt Sicherheitsforschern, wohin sie eine gefundene Lücke melden sollen. Sie ist eine schlichte Textdatei unter /.well-known/security.txt, in fünf Minuten angelegt und nach RFC 9116 genormt. Nach einer BSI-Messung haben sie nur 1,8 % der deutschen Websitebetreiber (berichtet von heise online am 10. August 2026) — über 98 % verzichten damit auf eine etablierte Kontaktmöglichkeit.

Dieses Werkzeug erzeugt Ihnen eine gültige Datei: kostenlos, ohne Konto, ohne Anmeldung. Wir speichern nichts davon.

Ihre Domain

Meldewege

Die Reihenfolge zählt: Der erste Eintrag gilt nach RFC 9116 als bevorzugter Weg. Erlaubt sind eine E-Mail-Adresse, eine Telefonnummer (tel:+49…) oder die https-Adresse eines Meldeformulars.

1. bevorzugt

2. weiterer Weg (optional)

3. weiterer Weg (optional)

Gültig für Die von RFC 9116 empfohlene Höchstdauer. Tragen Sie sich eine Erinnerung ein, sonst läuft die Datei unbemerkt ab.

Weitere Felder (optional)

Richtlinie zur Offenlegung (Policy) Eine Seite, die sagt, wie Sie mit Meldungen umgehen. Drei Absätze genügen — ein Beispiel ist unsere eigene.

Öffentlicher Schlüssel (Encryption) Nur ausfüllen, wenn unter dieser Adresse wirklich ein Schlüssel liegt. Das Feld enthält den Verweis, nie den Schlüssel selbst.

Zwei weitere Felder aus RFC 9116 bieten wir bewusst nicht an: Hiring ist ein Stellenanzeigen-Verweis und hat in einem Meldeweg nichts zu suchen, und CSAF zeigt ohne betriebene provider-metadata.json ins Leere. Wer CSAF betreibt, weiß es — und trägt die Zeile selbst nach.

So sieht eine security.txt aus

Ein vollständiges Beispiel — tragen Sie oben Ihre Angaben ein, um es durch Ihre eigene Datei zu ersetzen.

Noch nicht zum Veröffentlichen geeignet: Die Datei enthält einen Platzhalter oder eine Angabe musste weggelassen werden. Die Gründe stehen darunter.

Contact: mailto:IHRE-ADRESSE
Expires: 2027-09-16T00:00:00Z
Preferred-Languages: de, en
Canonical: https://ihre-domain.de/.well-known/security.txt

Text markieren und mit Strg+C kopieren — oder den Knopf benutzen, sofern JavaScript aktiv ist.

Was Sie dazu wissen sollten

Weggelassen: Ohne Meldeweg ist die Datei wertlos. Es steht deshalb ein sichtbarer Platzhalter darin — tragen Sie eine Adresse ein, die auch gelesen wird, bevor Sie die Datei veröffentlichen.
Kein Policy-Feld: Das ist zulässig. Wer Software in Verkehr bringt, braucht nach dem Cyber Resilience Act neben der Kontaktstelle auch eine Richtlinie zur koordinierten Offenlegung — dafür genügt eine Seite mit drei Absätzen.
Die Datei gehört nach https://ihre-domain.de/.well-known/security.txt und muss über HTTPS als text/plain; charset=utf-8 ausgeliefert werden (RFC 9116, Abschnitt 3).
Achtung: Diese Datei gilt bis zum 16.09.2027. Tragen Sie sich jetzt eine Erinnerung ein — nach diesem Tag ist sie nach RFC 9116 ungültig, und unser Prüfkatalog wertet sie dann als Mangel.
Eine security.txt ist nicht gesetzlich vorgeschrieben. Für Hersteller von Produkten mit digitalen Elementen ist sie der übliche Weg, die vom Cyber Resilience Act (EU 2024/2847) verlangte Kontaktstelle bereitzustellen — eine reine Firmenwebsite ist kein solches Produkt.
Die Reihenfolge der Sprachen ist keine Rangfolge — RFC 9116 behandelt alle genannten Sprachen als gleichwertig. Wer eine bevorzugen will, nennt nur diese.
Achtung: Achtung: In dieser Fassung steht ein Platzhalter. Sie würde unseren eigenen Prüfkatalog bestehen — das Contact-Feld ist ja vorhanden —, aber niemanden erreichen.

In fünf Schritten zur eigenen security.txt

Meldeweg festlegen. Entscheiden Sie, wohin eine Meldung über eine Sicherheitslücke gehen soll: ein Postfach, eine Telefonnummer oder ein Meldeformular. Wichtig ist nur, dass die Adresse wirklich gelesen wird — ein Meldeweg, den niemand beobachtet, ist schlechter als keiner.
Datei erzeugen. Tragen Sie den Meldeweg oben ein und lassen Sie sich die Datei erzeugen. Sie enthält die von RFC 9116 verlangten Felder Contact und Expires sowie einige empfohlene.
Datei ablegen. Speichern Sie den Text als Datei mit dem Namen security.txt im Ordner .well-known im Wurzelverzeichnis Ihrer Website, sodass sie unter https://ihre-domain.de/.well-known/security.txt erreichbar ist. Sie muss über HTTPS als text/plain ausgeliefert werden.
Aufrufen und prüfen. Rufen Sie https://ihre-domain.de/.well-known/security.txt im Browser auf. Erscheint der Text, ist alles richtig. Erscheint eine Fehlermeldung, liegt die Datei am falschen Ort oder wird vom Webserver nicht ausgeliefert.
Erinnerung eintragen. Notieren Sie sich das Ablaufdatum im Kalender. Nach diesem Tag ist die Datei nach RFC 9116 ungültig, und Prüfwerkzeuge behandeln sie als nicht vorhanden. Das ist der häufigste Fehler bei Websites, die eine security.txt haben.

Häufige Fragen

Ist eine security.txt Pflicht?

Nein. Eine security.txt ist nicht gesetzlich vorgeschrieben. Für Hersteller von Produkten mit digitalen Elementen ist sie der übliche Weg, die vom Cyber Resilience Act (Verordnung (EU) 2024/2847) verlangte Kontaktstelle bereitzustellen. Eine reine Firmenwebsite ist kein solches Produkt und wird vom CRA in der Regel nicht erfasst.

Was gehört in eine security.txt?

Pflicht sind nach RFC 9116 genau zwei Felder: Contact mit dem Meldeweg und Expires mit dem Ablaufdatum. Empfohlen sind Canonical mit dem maßgeblichen Fundort, Policy mit der Richtlinie zur Offenlegung und Preferred-Languages mit den Sprachen, in denen Sie Meldungen annehmen.

Wohin gehört die Datei?

In den Ordner .well-known im Wurzelverzeichnis der Website, also unter den Pfad /.well-known/security.txt. Sie muss über HTTPS erreichbar sein und als text/plain ausgeliefert werden.

Wie lange darf das Ablaufdatum in der Zukunft liegen?

RFC 9116 empfiehlt weniger als ein Jahr. Der Sinn des Feldes ist die Zusage, dass der genannte Meldeweg noch beobachtet wird — ein Datum in ferner Zukunft sagt darüber nichts aus.

Wie verbreitet ist die security.txt in Deutschland?

Nach einer Messung des BSI, über die heise online am 10. August 2026 berichtete, stellen nur 1,8 Prozent der untersuchten deutschen Websitebetreiber eine security.txt bereit. Über 98 Prozent verzichten damit auf eine etablierte Kontaktmöglichkeit.

Was passiert nach dem Ablaufdatum?

Die Datei gilt als ungültig. Prüfwerkzeuge und Sicherheitsforscher behandeln sie dann so, als gäbe es sie nicht. Der Prüfkatalog von Tutador wertet eine abgelaufene security.txt ausdrücklich als Mangel.

Und ist die Datei nachher wirklich in Ordnung?

Das können Sie prüfen lassen. Tutador ruft /.well-known/security.txt ab und kontrolliert die Pflichtfelder nach RFC 9116 — zusammen mit 21 weiteren Kriterien zu Verschlüsselung, Sicherheits-Kopfzeilen, DSGVO-Pflichten und E-Mail-Absicherung.

Website kostenlos prüfen