Ein fester Ort für Sicherheitshinweise
Jemand entdeckt eine Auffälligkeit an Ihrer Website und möchte sie melden. Muss diese Person erst zwischen Vertrieb, Support und mehreren Dienstleistern suchen, entsteht vermeidbare Verzögerung. Ein klarer Meldeweg hilft beiden Seiten: Die meldende Person findet ein Ziel, und Ihr Unternehmen erhält einen Hinweis, den es gezielt einordnen kann.
RFC 9116 beschreibt security.txt. Für Webdienste liegt die Datei unter /.well-known/security.txt und wird über HTTPS abgerufen. Contact und Expires sind Pflichtfelder.
Für die Einführung empfehlen wir eine einfache Bestandsaufnahme: Welche öffentlich erreichbaren Domains gehören zu Ihnen, wer betreibt sie, und an welche Stelle sollen Hinweise jeweils gehen? Stimmen Sie den Kontakt mit den tatsächlich zuständigen Personen ab, bevor Sie ihn veröffentlichen. [1]
Ein Postfach braucht eine Verantwortung
Benennen Sie eine verantwortliche Person und eine Vertretung. Vereinbaren Sie, wer den Eingang prüft, wer technische Fragen bewertet und wer bei Abwesenheit übernimmt. Bei mehreren Dienstleistern sollte vorher feststehen, welcher Anbieter für welchen Dienst zuständig ist.
Planen Sie einen ausdrücklich abgestimmten, harmlosen Zustelltest mit einer eindeutigen Betreffzeile. Prüfen Sie dabei mehr als den erfolgreichen Versand: Kommt die Nachricht im vorgesehenen Eingang an, erscheint sie in der Bearbeitung, und kann die zuständige Person antworten? Eine erreichbare Datei beantwortet diese Fragen noch nicht.
Ein gemeinsames Ticket oder eine interne Vorgangsnummer kann genügen. Halten Sie Empfangszeit, betroffenen Dienst, zuständige Person und nächsten Schritt fest. Vermeiden Sie, sensible Inhalte unnötig an große Verteiler weiterzuleiten.
Der Meldeweg auf einen Blick
Die Grafik trennt vier Aufgaben. Die veröffentlichte Datei zeigt den Kontakt. Der Eingang nimmt die Meldung auf. Die zuständige Person prüft den Bezug zum eigenen System. Eine Rückmeldung hält den Austausch offen.
Das lässt sich auch in einem kleinen Team organisieren. Entscheidend ist eine eindeutige Übergabe: Wer hat den Vorgang jetzt, welche Frage ist noch offen, und bis wann wird der nächste Schritt geprüft? Für einen extern betriebenen Dienst gehört die Übergabe an den Anbieter dazu.
/.well-known/security.txt
Öffentlich auffindbar
Contact:Meldeadresse oder Formular
Expires:Gültigkeitsende der Angaben
Eingang
Meldung erfassen und Eingang bestätigen.
Zuständigkeit
Betroffenen Dienst und verantwortliche Person zuordnen.
Rückmeldung
Nächsten Schritt und Rückkanal festhalten.
Die Datei macht den Eingang auffindbar. Zuständigkeit und Rückmeldung werden im Unternehmen organisiert.
Kontakt und Prüfregeln gehören zusammen
Eine veröffentlichte Kontaktadresse ist für sich genommen keine Beauftragung einer Sicherheitsprüfung. Trennen Sie deshalb das Melden einer Beobachtung von der Erlaubnis, weitere Tests durchzuführen.
Das NCSC empfiehlt eine verständliche Disclosure-Policy: Kontaktweg, benötigte Angaben, erwartete Reaktion und Grenzen der zulässigen Untersuchung werden darin beschrieben.
Für die erste Nachricht empfehlen wir die betroffene Adresse, eine kurze Beschreibung und den Zeitpunkt der Beobachtung. Zugangsdaten und umfangreiche personenbezogene Datensätze sind dafür nicht erforderlich. Falls weitere Nachweise nötig sind, vereinbaren Sie einen geeigneten Übermittlungsweg. Versprechen Sie öffentlich nur Reaktionszeiten, die Ihr Team zuverlässig einhalten kann. [2]
Beim nächsten Wechsel mitprüfen
Behandeln Sie den Sicherheitskontakt wie andere betriebliche Kontaktdaten. Nehmen Sie ihn in die Checkliste für Domainumzüge, neue IT-Dienstleister und Personalwechsel auf. Legen Sie vor dem Gültigkeitsende einen Termin zur Kontrolle an.
Eine kompakte Wiederholungsprüfung reicht als Einstieg: öffentliche Datei abrufen, Angaben mit der internen Zuständigkeit abgleichen und den vereinbarten Meldeweg kontrollieren. Dokumentieren Sie das Ergebnis mit Datum. So wird aus einer einmal abgelegten Datei ein gepflegter Zugang für verwertbare Sicherheitshinweise.
Felder und Auslieferung gezielt prüfen
Die Datei muss für Webdienste per HTTPS unter /.well-known/security.txt als UTF-8-Text mit dem Medientyp text/plain erreichbar sein. Eine HTML-Fehlerseite mit Status 200 ist keine gültige security.txt. Prüfen Sie Inhalt und Antwortheader gemeinsam.
Der Domainbezug ist eng: Eine Datei auf example.com gilt nicht automatisch für alle Subdomains. Erfassen Sie deshalb jeden vorgesehenen Host. Die folgenden Felder sind eine Auswahl, keine vollständige Konformitätsprüfung nach RFC 9116. [1]
Die Tabelle lässt sich seitlich verschieben.
| Feld | Anforderung | Praktische Kontrolle |
|---|---|---|
| Contact | Pflicht; mindestens eine Kontakt-URI. | Für E-Mail mailto: verwenden; Zustellung vorher vereinbaren und prüfen. |
| Expires | Pflicht; genau ein RFC-3339-Zeitpunkt. | Gültigkeit prüfen und Aktualisierung vor Ablauf einplanen; empfohlen ist weniger als ein Jahr im Voraus. |
| Preferred-Languages | Optional; tatsächlich unterstützte Sprachen. | Nur Sprachen nennen, in denen Hinweise bearbeitet werden können. |
| Canonical | Optional; vorgesehene HTTPS-Adresse der Datei. | Mit der tatsächlichen Abrufadresse abgleichen. |
| Policy | Optional; Link zur Offenlegungsrichtlinie. | Kontaktweg, erlaubten Umfang und Rückmeldung verständlich beschreiben. |
Prüfung und Verantwortlichkeit festhalten
Die ausfüllbare Checkliste verbindet die öffentliche Datei mit dem internen Meldeweg. Je Domain eine Kopie verwenden, tatsächliche Ergebnisse eintragen und eine erneute Prüfung terminieren. Sie ist kein automatischer Scanner und bestätigt allein keine sichere Konfiguration.