security.txt für eine persönliche Website — Eine klare Anlaufstelle für Sicherheitsmeldungen

Eine persönliche Website mag klein sein, doch auch sie hat Türen, Fenster und gelegentlich ein loses Scharnier. Wenn ein Sicherheitsforscher ein Problem entdeckt, kann eine einzige kleine Textdatei darüber entscheiden, ob daraus eine hilfreiche Meldung oder stille Frustration entsteht.

Diese Datei heißt security.txt. Sie sichert einen Server nicht von selbst ab und ersetzt weder Patching und Monitoring noch eine sorgfältige Konfiguration. Ihre Aufgabe ist enger gefasst: Sie zeigt wohlmeinenden Menschen, wie sie Kontakt aufnehmen können, was sie erwarten dürfen und wo die Grenzen liegen.

Was security.txt tatsächlich leistet

security.txt ist ein standardisiertes Kontaktdokument, das in RFC 9116 beschrieben wird. Sicherheitsforscher und automatisierte Tools suchen danach unter /.well-known/security.txt. Man kann es sich wie eine Notfallkarte am Eingang eines Gebäudes vorstellen. Die Karte baut keine besseren Schlösser ein, verhindert aber, dass jemand, der Rauch bemerkt, auf der Suche nach dem Eigentümer durch jeden Flur laufen muss.

Ohne einen veröffentlichten Kontaktweg probiert ein Hinweisgeber vielleicht ein altes Social-Media-Konto aus, errät eine E-Mail-Adresse, schreibt einen öffentlichen Kommentar oder gibt auf. Eine eindeutige Datei verringert diese Unsicherheit. Außerdem lassen sich Präferenzen angeben, etwa ob Meldungen verschlüsselt werden sollen, welche Sprachen verstanden werden und wo die Disclosure Policy zu finden ist.

Die kleinste sinnvolle Datei

Eine praktische Datei kann mit nur zwei wesentlichen Angaben beginnen: einem funktionierenden Kontakt und einem Ablaufdatum. Als Kontakt eignet sich eine E-Mail-Adresse oder ein HTTPS-Formular. Das Ablaufdatum signalisiert Tools und Forschern, dass die Hinweise weiterhin gepflegt werden und nicht seit Jahren vergessen sind.

Contact: mailto:[email protected]
Expires: 2027-08-14T00:00:00Z
Preferred-Languages: en, id, de
Canonical: https://example.com/.well-known/security.txt

Die Beispieldomain und das Postfach müssen durch Adressen ersetzt werden, die tatsächlich überwacht werden. Das Ablaufdatum sollte komfortabel in der Zukunft liegen, aber nicht so weit, dass die Datei in Vergessenheit gerät. Sechs bis zwölf Monate sind ein vernünftiger Wartungsrhythmus. Die Erneuerung gehört in denselben Kalender wie Erinnerungen an Domains, Zertifikate und Backups.

Nützliche Felder ohne unnötige Versprechen

Das Feld Contact darf mehrfach vorkommen, sodass sowohl E-Mail als auch Webformular angeboten werden können. Encryption verweist auf einen öffentlichen Schlüssel, wenn sensible Meldungen sicher empfangen werden können. Acknowledgments führt zu einer Seite, die Helfern dankt, während Policy Regeln für verantwortungsvolle Tests verlinkt. Auch Hiring ist vorgesehen, wird von den meisten persönlichen Websites jedoch nicht benötigt.

Veröffentlicht werden sollten nur Felder, die wirklich unterstützt werden. Ein unbeobachtetes „Security“-Postfach ist schlechter als eine vertraute Adresse, die täglich gelesen wird. Ebenso sollte niemand eine Reaktion innerhalb von 24 Stunden oder eine Geldprämie versprechen, wenn das nicht zuverlässig möglich ist. Eine bescheidene Aussage wie „Ich versuche, Meldungen innerhalb von sieben Tagen zu bestätigen“ ist glaubwürdiger als ein eindrucksvolles Serviceziel, das nur auf dem Papier steht.

Eine verständliche Disclosure Policy verfassen

Die Textdatei ist ein Wegweiser; eine Policy-Seite liefert den Kontext. Sie sollte erklären, welche Systeme zum Scope gehören, welche Tests nicht erlaubt sind, welche Informationen eine nützliche Meldung enthalten soll und wie die Kommunikation abläuft. Bei einer persönlichen Website könnten die Hauptdomain und eigene Subdomains dazugehören, Dienste von Drittanbietern dagegen nicht.

Forscher sollten gebeten werden, Datenschutzverletzungen, Datenzerstörung, Denial-of-Service-Tests, Social Engineering und den Zugriff auf mehr Daten als für den Nachweis nötig zu vermeiden. Hilfreich sind die betroffene URL, Schritte zur Reproduktion, die beobachtete Auswirkung und ein sicherer Proof of Concept. Das ähnelt einer Reparaturanleitung neben einem Fahrrad: Je klarer Werkzeuge und Grenzen beschrieben sind, desto geringer ist die Gefahr, dass Hilfe ein zweites Problem verursacht.

Am richtigen Ort veröffentlichen

Der Standardort ist festgelegt: https://example.com/.well-known/security.txt. Eine ältere Kopie darf zusätzlich unter /security.txt liegen, doch die Route unter /.well-known/ ist maßgeblich. Die Datei sollte über HTTPS mit einem textbasierten Content-Type ausgeliefert werden und weder hinter einer Anmeldung oder einem Cookie-Banner noch in einer reinen JavaScript-Anwendung verborgen sein.

Bei einer statischen Website wird das Verzeichnis angelegt und die Datei zusammen mit den übrigen öffentlichen Assets versioniert. In Nginx kann eine direkte Location die Antwort eindeutig festlegen:

location = /.well-known/security.txt {
    default_type text/plain;
    try_files /.well-known/security.txt =404;
}

Wenn ein Framework jede Anfrage abfängt, braucht dieser Pfad eine Ausnahme oder die Datei muss in dessen Public-Verzeichnis liegen. Eine lange Redirect-Kette über fremde Domains sollte vermieden werden. Der Wert von Canonical muss mit dem endgültigen HTTPS-Ort übereinstimmen, von dem die Datei ausgeliefert wird.

Signieren ist optional, Korrektheit nicht

RFC 9116 unterstützt digital signierte Inhalte. Eine Signatur kann die Echtheit der Anweisungen belegen, besonders bei größeren Organisationen mit etablierten PGP-Abläufen. Für eine kleine persönliche Website ist eine unsignierte Datei, die über korrekt konfiguriertes HTTPS bereitgestellt wird, oft ein vernünftiger Anfang.

Die Komplexität des Signierens sollte einen nützlichen Kontaktweg nicht verzögern. Eine perfekte Signatur um ein abgelaufenes Datum oder ein totes Postfach hilft niemandem. Wichtiger ist die operative Korrektheit: Der Empfänger muss aktiv bleiben, das Postfach durch starke Authentifizierung geschützt, der Zugriff auf Meldungen begrenzt und jeder Anhang oder Proof-of-Concept-Code als nicht vertrauenswürdige Eingabe behandelt werden.

Das öffentliche Ergebnis testen

Nach der Veröffentlichung sollte geprüft werden, was ein Außenstehender tatsächlich erhält, statt nur der lokalen Datei zu vertrauen. Die folgenden Befehle zeigen Status, Header, Redirects und Inhalt:

curl -i https://example.com/.well-known/security.txt
curl -L https://example.com/.well-known/security.txt

Erwartet werden eine erfolgreiche Antwort, lesbarer Plain Text und exakt die aktuellen Anweisungen. Bei einer selbst gehosteten Website sollte der Test auch außerhalb des Heimnetzes erfolgen. Danach ist der Kontaktweg selbst zu testen. Eine harmlose Nachricht zeigt, ob Spamfilter, Aliase und Weiterleitungsregeln wirklich zustellen. Ein Weg ist erst dann real, wenn die Nachricht einen Menschen erreicht.

Auf die Meldung vorbereitet sein

Mit der Veröffentlichung von Kontaktdaten entsteht die Verantwortung, ruhig zu reagieren. Dafür genügt ein schlanker Ablauf: Eingang bestätigen, Originalmeldung aufbewahren, Problem sicher reproduzieren, Schweregrad einschätzen, Änderung beheben und prüfen sowie anschließend den Zeitpunkt der Veröffentlichung abstimmen. Nicht jedes überraschende Verhalten ist eine Schwachstelle, doch jede respektvolle Meldung verdient eine respektvolle Antwort.

Hinweisgeber sollten keine Geheimnisse senden müssen, die für die Untersuchung unnötig sind. Betrifft ein Problem personenbezogene Daten, sind Kopien zu minimieren und das Gespräch sollte, wenn möglich, in einen verschlüsselten Kanal wechseln. Kurze Notizen helfen später zu erkennen, ob die Ursache fehlende Updates, unsichere Standardwerte, offengelegte Zugangsdaten oder eine überholte Designannahme war.

Eine kleine Datei verbessert das gesamte Gespräch

security.txt ist keine glamouröse Infrastruktur. Sie ähnelt eher einer Beschriftung am Sicherungskasten: eine kleine Wartungsarbeit, die genau dann wertvoll wird, wenn etwas schiefläuft. Sie bringt Forscher zur richtigen Person, liefert dem Betreiber genügend Kontext und setzt Grenzen, bevor Dringlichkeit das Gespräch verzerrt.

Ein überwachter Kontakt, ein Ablaufdatum, bevorzugte Sprachen und die kanonische URL genügen für den Anfang. Später kann eine kurze Policy hinzukommen; anschließend sollten der Pfad aus dem öffentlichen Internet getestet und die Erneuerung eingeplant werden. Wer eine persönliche Website betreibt, kann heute prüfen, ob die eigene Datei unter /.well-known/security.txt bereits existiert. Teile in den Kommentaren, welche Felder du verwendest oder welche Schwierigkeiten auftreten, damit auch andere Betreiber kleiner Websites eine klarere Anlaufstelle schaffen können.