Sicherheits-Ratgeber
security.txt, erklärt
Jemand hat eine Lücke in Ihrer Website gefunden und möchte Ihnen das sagen. Über diese eine Textdatei findet die Person heraus, wohin sie schreiben soll, und veröffentlicht ist sie in zehn Minuten.
01 Warum das zählt
Die Meldung, die Sie nie bekommen haben
Wer eine Schwachstelle auf Ihrer Seite findet, hat ein kurzes Zeitfenster guten Willens. Die Person sucht eine Stelle, an die sie das schicken kann, und findet ein Kontaktformular mit dem Versprechen einer Antwort binnen fünf Werktagen, eine Support-Adresse, hinter der niemand die Meldung versteht, oder gar nichts. Was danach passiert, ist selten Bosheit: sie gibt auf, sie stellt es öffentlich, um Aufmerksamkeit zu bekommen, oder sie verkauft es. Alle drei sind für Sie schlechter als eine Mail.
security.txt ist die vereinbarte Antwort darauf, standardisiert als RFC 9116. Es ist eine Textdatei an einer bekannten Stelle, die sagt, an wen man sich wendet und was einen erwartet. Sie kostet nichts, sie ist maschinenlesbar und wird deshalb von Scannern und Forschern automatisch gefunden, und schon ihre Existenz signalisiert, dass eine Meldung bei jemandem ankommt, der sie haben will.
02 Die Felder
Zwei Pflichtfelder, vier sinnvolle Ergänzungen
Pflicht sind nur Contact und Expires. Der Rest spart Rückfragen zwischen dem Finder und Ihrem Team, und genau darum geht es bei der Datei.
Contact
Was es macht. Nennt die Stelle, an die eine Meldung geht. Eine mailto:-Adresse, eine Telefonnummer oder eine https:-Adresse eines Meldeformulars; das Feld darf mehrfach vorkommen, in absteigender Priorität.
Warum es zählt. Für dieses eine Feld gibt es die Datei überhaupt. Nehmen Sie eine Adresse, die bei einem Menschen ankommt, und keine Ticket-Warteschlange, die unbekannte Post schließt, und bevorzugen Sie eine Rollenadresse vor einer Person, damit sie deren Weggang übersteht.
Contact: mailto:security@example.com Expires
Was es macht. Ein Zeitpunkt, ab dem der Datei nicht mehr vertraut werden soll. Seit RFC 9116 Pflicht, angegeben im ISO-8601-Format.
Warum es zählt. Es verhindert, dass eine vergessene Datei dauerhaft auf eine Adresse zeigt, die niemand mehr liest. Setzen Sie den Wert auf weniger als ein Jahr und tragen Sie die Erneuerung in denselben Kalender wie Ihre Zertifikate ein, denn eine abgelaufene security.txt gilt wie gar keine.
Expires: 2027-01-31T23:59:00.000Z Encryption
Was es macht. Verweist auf einen öffentlichen Schlüssel, mit dem eine meldende Person ihre Nachricht verschlüsseln kann, als Adresse und nicht als Schlüssel selbst.
Warum es zählt. Eine Schwachstellenmeldung ist die eine Mail, die Sie am wenigsten mitgelesen haben möchten. Der Schlüssel ist optional, aber wer einen sucht und keinen findet, schickt die Details unter Umständen gar nicht.
Encryption: https://example.com/pgp-key.txt Policy
Was es macht. Verlinkt Ihre Richtlinie zur Schwachstellenmeldung: was im Geltungsbereich liegt, wie lange Sie für eine Antwort brauchen und worum Sie bitten, bevor jemand an die Öffentlichkeit geht.
Warum es zählt. Sie setzt auf beiden Seiten Erwartungen. Wer weiß, dass Sie binnen einer Woche antworten, wartet deutlich eher als jemand, der nichts gehört hat und rät.
Policy: https://example.com/security-policy Preferred-Languages
Was es macht. Nennt die Sprachen, die Ihr Sicherheitsteam liest, als kommagetrennte Liste von Sprachkennungen.
Warum es zählt. Klein, aber im DACH-Raum praktisch: wer deutsch an ein Team schreibt, das nur Englisch liest, oder umgekehrt, baut eine Übersetzungsrunde in etwas ein, das oft zeitkritisch ist.
Preferred-Languages: de, en Canonical
Was es macht. Gibt an, unter welcher Adresse die Datei ausgeliefert werden soll.
Warum es zählt. Damit lässt sich prüfen, ob die gefundene Datei dorthin gehört, wo sie gefunden wurde. Das zählt, sobald Ihre Inhalte gespiegelt oder unter mehreren Hostnamen ausgeliefert werden.
Canonical: https://example.com/.well-known/security.txt03 Einführung
Eine Datei, ein Ort
Die Datei gehört nach /.well-known/security.txt und muss über HTTPS mit dem Inhaltstyp text/plain ausgeliefert werden. Eine Kopie im Wurzelpfad ist für ältere Programme erlaubt, massgeblich ist aber der well-known-Ort. Nichts darin ist geheim, sie braucht also keinen Schutz ausser einer korrekten Auslieferung.
Contact: mailto:security@example.com Expires: 2027-01-31T23:59:00.000Z Preferred-Languages: de, en Canonical: https://example.com/.well-known/security.txt Policy: https://example.com/security-policyZwei Dinge gehen in der Praxis schief. Ein Webserver, der die Datei als text/html ausliefert, lässt sie durch automatische Prüfungen fallen, und ein Framework, das jeden unbekannten Pfad auf eine 404-Seite leitet, verschluckt sie. Rufen Sie die Adresse einmal selbst auf und sehen Sie sich Statuscode und Inhaltstyp an, nicht nur den Text im Browser.
04 Fragen
Was zu security.txt gefragt wird
Lädt eine veröffentlichte Kontaktadresse nicht zu Angriffen ein?
Sie ändert nichts daran, wer Ihre Seite abklopft. Automatisches Scannen läuft ohnehin und trifft jeden. Was die Datei ändert, ist, was ein Mensch mit dem Gefundenen macht, und die Alternative zu einer Meldung an Sie ist nicht Stille, sondern dass der Fund anderswo landet.
Wir sind ein kleiner Betrieb ohne Sicherheitsteam. Ist das etwas für uns?
Gerade für Sie. Die Datei verspricht kein Team, sie verspricht eine Adresse. Zeigen Sie auf die Person, die tatsächlich Post liest und Ihre Entwicklung oder Agentur erreicht, und schreiben Sie in die Richtlinie, dass Sie klein sind und binnen einer genannten Frist antworten.
Brauchen wir dafür ein Bug-Bounty-Programm?
Nein, das eine hat mit dem anderen nichts zu tun. security.txt sagt, wohin eine Meldung geht; ein Bounty sagt, was Sie dafür zahlen. Die meisten veröffentlichten Dateien bieten gar keine Belohnung, und das in der Richtlinie klar zu sagen, ist besser, als es offenzulassen.
Was passiert, wenn das Expires-Datum überschritten ist?
Prüfprogramme behandeln die Datei als ungültig, das Ergebnis ist also dasselbe, als hätten Sie nie eine veröffentlicht. Das Erneuern ist eine Zeile, aber es muss tatsächlich passieren, und deshalb gehört es auf dieselbe Wartungsliste wie Ihre Zertifikate und Ihre Domainverlängerungen.
05 Im Detail
Verwandte Sicherheitsthemen
Eine Kontaktadresse ist das, was nach einem Vorfall zählt. Diese Ratgeber behandeln den Teil davor.
HTTP-Security-Header
Was jeder Response-Header bewirkt, welche Ihre Website senden sollte und wie Sie sie richtig konfigurieren.
Content Security Policy
Der stärkste Schutz gegen Cross-Site-Scripting: welche Direktiven Sie setzen, wie Sie eine Richtlinie im Report-Only-Modus einführen und wie Sie erzwingend werden, ohne Ihre Website zu zerlegen.
HSTS
Strict-Transport-Security erklärt: was max-age, includeSubDomains und preload wirklich bewirken und warum die Preload-Liste eine Entscheidung ist, die Sie nicht schnell zurücknehmen können.
Cookie-Sicherheit
Secure, HttpOnly und SameSite: die Cookie-Attribute, die eine Sitzung vor Skripten und fremden Seiten schützen, samt Einstellungen für einen typischen Stack.
Clickjacking und X-Frame-Options
Wie eine unsichtbare Überlagerung aus einem Besucherklick eine Aktion auf Ihrer Website macht, und die zwei Header, die das verhindern: X-Frame-Options für ältere Clients, frame-ancestors für alles andere.
Referrer-Policy
Welcher Teil Ihrer URLs an fremde Seiten geht, wenn ein Besucher weiterklickt: die fünf Werte, die zählen, was jeder davon preisgibt und welcher der sinnvolle Standard ist.
Permissions-Policy
Kamera, Mikrofon, Standort und Bezahlfunktion für Ihre Website und alle eingebetteten Inhalte abschalten: die Syntax der Positivliste und warum eine nicht genannte Funktion keine abgeschaltete Funktion ist.
SPF, DMARC und DNSSEC
Die Einträge, die verhindern, dass jemand in Ihrem Namen Mails verschickt, und der, der Ihre DNS-Antworten ehrlich hält: was jeder leistet und in welcher Reihenfolge Sie sie einführen.
Security-Header überwachen
Ein Header, der heute stimmt, kann nach dem nächsten Deploy fehlen. Drei Wege, das zu bemerken: ein Cronjob mit curl, eine Prüfung in Ihrer CI-Pipeline und ein geplanter Scan, jeweils mit dem, was er findet und was nicht.
CSP-Änderungen erkennen
Wie sich eine Richtlinie durch Deploys, Plugins und CDN-Regeln unbemerkt ändert und wie Sie es merken: ein Header-Diff, Verstoßmeldungen über report-to und was ein Scan-Vergleich zeigen kann und was nicht.
Weiterlesen
Weitere Ratgeber
Jeder Ratgeber steht für sich, zusammen decken sie ab, worauf unser Scanner schaut. Wählen Sie den, der Ihrer nächsten Frage am nächsten kommt.
Sehen Sie, ob Ihre Seite eine security.txt veröffentlicht
Unser kostenloser Quickscan sucht die Datei an der Standardstelle, zusammen mit Ihren Security-Headern, und erklärt jeden Befund verständlich.