security.txt: Einen verlässlichen Meldeweg bereitstellen

Was die Datei regelt

RFC 9116 beschreibt ein maschinenlesbares Format für Kontakte und Hinweise zur Schwachstellenmeldung. Der RFC wurde im April 2022 als Informational veröffentlicht; er ist kein Internet Standard im formalen IETF-Status. Die enthaltenen Formatvorgaben sind dennoch die maßgebliche Grundlage für eine Datei nach RFC 9116. RFC 9116, Status und § 1

Für Webdienste ist der Ort https://example.com/.well-known/security.txt. Eine Datei oder Weiterleitung unter /security.txt dient der älteren Kompatibilität. Sie ersetzt die Bereitstellung im vorgeschriebenen /.well-known/-Pfad nicht. Sind Dateien an beiden Stellen vorhanden, hat die im Well-Known-Pfad Vorrang.

Eine Datei gilt zunächst für den Host beziehungsweise die IP-Adresse ihrer Abruf-URI, nicht automatisch für alle Eltern- und Subdomains. www.example.com, example.com und shop.example.com deshalb gesondert betrachten. Der veröffentlichte Prozess kann zusätzlich Produkte und Dienste einer Organisation abdecken; diesen Umfang beschreibt die Policy. Aus einer bloßen Kontaktdatei lässt sich diese weitergehende Zuständigkeit nicht erraten. RFC 9116, § 3

Pflichtfelder korrekt ausfüllen

Eine nackte E-Mail-Adresse wie security@example.com reicht als Contact-Wert nicht: Das Schema mailto: gehört dazu. Für Telefonkontakte wird tel: verwendet, für Webkontakte eine HTTPS-URI. Mehrere Kontakte werden nicht einfach durch Kommas in einer Contact-Zeile verbunden. Ein Formular sollte für externe Hinweisgeber tatsächlich erreichbar sein und einen sicheren Weg zur Übermittlung der nötigen Informationen bieten.

Expires bezeichnet den Zeitpunkt, ab dem die Datei als veraltet gilt. Ein Datum ohne Uhrzeit oder ein Zeitpunkt ohne Offset erfüllt das verlangte Format nicht. Z steht für UTC; beispielsweise ist auch ein passender numerischer Offset möglich. Die Empfehlung des RFC lautet weniger als ein Jahr in die Zukunft, keine zwingende allgemeine Jahreslaufzeit. Wählen Sie einen Termin, den Sie mit Ihrer Pflegeorganisation einhalten können. RFC 9116, §§ 2.5.3 und 2.5.5, RFC 3339, § 5.6

Ein Prüfprogramm, das eine Zeichenkette irgendwie als Datum lesen kann, hat damit noch nicht RFC 3339 geprüft. Ebenso beweist ein Datum in der Zukunft nicht, dass das Postfach betreut wird. Ablaufwarnung und regelmäßige Kontrolle des tatsächlichen Meldewegs ergänzen sich.

Optionale Felder nach Bedarf ergänzen

Web-URIs in diesen Feldern müssen HTTPS verwenden. Eine Encryption-URI ist kein Nachweis, dass der Schlüssel richtig zugeordnet oder aktuell ist. Der dort angegebene Verschlüsselungsschlüssel muss auch nicht der Signaturschlüssel der Datei sein. Fehlt Preferred-Languages, dürfen Hinweisgeber nach RFC 9116 Englisch annehmen.

Die Felderliste ist erweiterbar. Die aktuelle IANA-Registry enthält zusätzlich beispielsweise CSAF für ein entsprechendes Sicherheitsberatungs-Verzeichnis und Bug-Bounty mit einem Wahr-/Falsch-Wert. Das bedeutet weder eine Pflicht zu einem Prämienprogramm noch eine bestimmte Vergütung. Unbekannte Felder müssen Leser ignorieren; zusätzliche Felder machen fehlende Pflichtfelder nicht gültig. IANA-Registry

Ein überschaubares Dateibeispiel

Die Domains, Adressen und der Zeitpunkt sind Platzhalter für dieses Beispiel. Übernehmen Sie nur erreichbare, von Ihrer Organisation betreute Ziele; prüfen Sie den Ablaufzeitpunkt vor jeder Veröffentlichung:

# Sicherheitsmeldungen für example.com
Contact: mailto:security@example.com
Contact: https://example.com/security/contact
Expires: 2027-01-31T23:59:59Z
Preferred-Languages: de, en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security/policy
Encryption: https://example.com/security/pgp-key.asc

Die Datei besteht aus UTF-8-Klartext, nicht aus HTML. Jedes Feld steht auf einer eigenen Zeile, im Beispiel mit einem Leerzeichen nach dem Feld-Doppelpunkt. Auch die letzte Zeile endet mit einem Zeilenumbruch. LF oder CRLF sind für die normalen Textzeilen vorgesehen. Kommentare beginnen mit #. Feldnamen sind ohne Beachtung der Groß-/Kleinschreibung definiert; ihre einheitliche Schreibweise erleichtert die Pflege.

Halten Sie die Datei klein. Der RFC erlaubt Lesern zum Schutz ihrer Parser begrenzte Größen- und Zeilenlängen; er verlangt keine große Beschreibung der gesamten Sicherheitsorganisation in dieser Datei. Längere Regeln gehören auf die verlinkte Policy-Seite.

Bereitstellung im wirklichen Auslieferungsweg prüfen

Die öffentliche Antwort braucht HTTPS mit gültigem Zertifikat und Content-Type: text/plain; charset=utf-8. Ein Status 200 mit Ihrer normalen HTML-Fehlerseite ist keine security.txt. Auch eine Anmeldung, ein Bot-Challenge-Formular oder ein auf die Startseite zeigender SPA-Fallback kann die Auffindbarkeit verhindern.

Bei einem Webserver muss der öffentliche Pfad zur richtigen Datei beziehungsweise Route führen. Prüfen Sie Regeln, die versteckte Verzeichnisse generell sperren, sowie die Reihenfolge von Rewrite-, Zugriffsschutz- und Fallback-Regeln. Bei Nginx lässt sich der konkrete Pfad etwa über einen exakt passenden location-Block zuordnen; bei Apache muss eine gezielte Ausnahme zur tatsächlichen Verzeichnis- und Rewrite-Konfiguration passen. Eine allgemeine Rewrite-Ausnahme für ganz /.well-known/ gewährt nicht automatisch Dateizugriff und setzt auch den MIME-Typ nicht.

CDN und WAF gehören zum gleichen Prüfweg. Ein korrigiertes Origin-Dokument hilft nicht, solange ein Cache noch die alte Datei ausliefert. Wählen Sie eine Cache-Laufzeit, die Aktualisierungen, Widerruf und Expires nicht unterläuft, und sorgen Sie für einen gezielten Austausch. Erreichbarkeit, Ablauf und Änderungen an Contact, Canonical oder Schlüsselverweisen sollten überwacht werden.

Für die eigene Domain können Sie mit einem GET-Abruf Status, Header, Inhalt und Weiterleitungen sichtbar machen:

curl --proto '=https' --proto-redir '=https' \
  --location --max-redirs 3 --max-time 15 --dump-header - \
  'https://example.com/.well-known/security.txt'

Der Befehl verwendet keine Zertifikatsausnahme. Er prüft damit noch nicht die RFC-Grammatik oder die Erreichbarkeit des Postfachs. Dokumentieren Sie unerwartete Zielwechsel und den abschließenden Pfad. Weiterleitungen sind möglich, verdienen aber eine eigene Vertrauensprüfung, besonders beim Wechsel zu einer anderen Domain. RFC 9116, §§ 3 und 5.2

Signatur, Integrität und Vertrauen auseinanderhalten

RFC 9116 empfiehlt eine OpenPGP-Cleartextsignatur und dazu ein Canonical-Feld. Die Signatur schützt den unterschriebenen Text gegen unbemerkte Änderung, wenn sie mit dem richtigen, vertrauenswürdig zugeordneten öffentlichen Schlüssel geprüft wird. Sie beweist nicht von selbst, dass dieser Schlüssel Ihrer Organisation gehört.

Ein sichtbarer Block BEGIN PGP SIGNED MESSAGE oder BEGIN PGP SIGNATURE genügt nicht. Die kryptografische Prüfung muss die Signatur tatsächlich bestätigen. Bei fehlendem öffentlichen Schlüssel bleibt sie ungeprüft; eine ungültige Signatur ist ein anderer Befund. Eine lokal durchgeführte Probe bestätigte genau diese Unterschiede: Original gültig, geänderte Contact-Zeile ungültig, unbekannter Schlüssel nicht prüfbar.

Canonical ergänzt den Ortsbezug. Wird eine korrekt signierte Datei unverändert auf einen fremden Host kopiert, kann die Signatur weiterhin mathematisch passen. Bei vorhandenem Canonical-Feld, das die Abruf-URI nicht enthält, sollen die Inhalte nach RFC 9116 nicht als vertrauenswürdig behandelt werden. Umgekehrt autorisiert eine Liste von Canonical-URIs nicht allein jede darin genannte fremde Adresse. RFC 9116, §§ 2.3, 2.5.2 und 5.1

Organisieren Sie Schlüsselpflege, Signierung nach Änderungen und eine unabhängige Möglichkeit zur Prüfung der Schlüsselzuordnung. Wer bereits Ihre Website verändert hat, könnte auch die Datei und einen dort verlinkten Schlüssel ersetzen. Für Hinweise auf einen schon laufenden Einbruch ist daher besondere Vorsicht geboten. Der Kontakt für Schwachstellenmeldung und der Krisenkommunikationsweg müssen nicht derselbe sein.

Hinter dem Kontakt einen betreuten Prozess einrichten

Legen Sie eine zuständige Rolle und eine Vertretung fest. Der Eingang braucht eine Triage, eine sichere Behandlung von Anhängen und Links sowie eine Möglichkeit, vertraulich nachzufragen. Eingehende Berichte sind unvertrauenswürdige Daten und können Spam oder schädliche Inhalte enthalten. Veröffentlichen Sie nur Reaktionszusagen, die Sie auch im Urlaub und bei erhöhtem Aufkommen einhalten können.

Eine zweckmäßige Policy beschreibt den erfassten Bereich, den Meldeweg, gewünschte Informationen, den Umgang mit sensiblen Daten und die weitere Kommunikation. Wenn Sie Sicherheitstests ausdrücklich erlauben möchten, müssen deren Bedingungen gesondert und verständlich festgelegt werden. Weder das Vorhandensein noch das Fehlen der Datei ist nach RFC 9116 als allgemeine Testerlaubnis oder deren Verweigerung zu verstehen. Der RFC schreibt auch keine pauschale Antwort innerhalb von 24–48 Stunden oder Triage binnen fünf Werktagen vor.

Kontrollieren Sie mindestens vor dem Ablauf sowie nach Änderungen an Organisation, Domains und Schlüsseln die veröffentlichten Angaben. Setzen Sie Expires nicht einfach automatisch weiter, ohne die Informationen zu prüfen. Veraltete Kontakte können vertrauliche Hinweise an inzwischen unzuständige Empfänger lenken.

Gesetzliche Meldungen sind ein eigener Prozess

Die Datei ist keine allgemeine Voraussetzung für „NIS2-Compliance“. Art. 12 NIS2 regelt die nationale Koordination der Schwachstellenoffenlegung. Meldepflichten für erhebliche Sicherheitsvorfälle sind davon zu unterscheiden; für erfasste Einrichtungen in Deutschland gilt insbesondere § 32 BSIG. Ein Hinweis an das veröffentlichte Contact-Postfach ist keine solche Behördenmeldung. NIS2, Art. 12 und 23, § 32 BSIG

Beim Cyber Resilience Act sind Produkt, Herstellerrolle und Anwendungsbereich entscheidend; nicht jede Website ist automatisch ein erfasstes Produkt. Die Hersteller-Meldepflichten des Art. 14 gelten seit dem 11. September 2026, auch für einschlägige Altprodukte nach Art. 69 Abs. 3. Die allgemeinen Anforderungen an Schwachstellenbehandlung mit Offenlegungsstrategie und Kontaktadresse gelten grundsätzlich ab dem 11. Dezember 2027. Eine security.txt kann einen Kontakt auffindbar machen, ersetzt aber weder diese Prozesse noch die erforderlichen Meldungen. CRA, Art. 13–14, 69, 71 und Anhang I Teil II

Auch im Audit kommt es auf den vereinbarten Prüfrahmen und tatsächliche Nachweise an. Ein Contact- oder Policy-Feld ist keine Zertifizierung. Die rechtliche Einordnung vertieft der bestehende Compliance-Ratgeber.

Was der Scanner tatsächlich untersucht

Der Web Security Check ruft im geprüften Stand für den angefragten Host den Well-Known-Pfad über HTTPS ab und versucht unter bestimmten Bedingungen den älteren Wurzelpfad. Dieser Nebenabruf ist vom finalen Host einer vorherigen Webseitenweiterleitung zu unterscheiden. Er hat Größen-, Zeit- und Redirectgrenzen. Ein Transportfehler belegt deshalb nicht, dass die Datei fehlt.

Der Analyzer erkennt ausgewählte Felder, beurteilt Expires und untersucht den Aufbau eines Cleartextsignaturblocks. Er prüft keine kryptografische Signatur, kein tatsächlich betreutes Postfach und keine vollständige Offenlegungspolicy. Contact-URIs und das Expires-Datum prüft er auf die vorgeschriebene Form; wesentliche Fehler dort verhindern eine gute Qualitätsstufe und Zusatzpunkte. Weitere URI-Felder, die Erreichbarkeit der Kontakte und Sonderfälle wie Schaltsekunden bewertet er nicht abschließend. Ein gültigkeitsähnlicher Qualitätswert oder zusätzliche Punkte dürfen daher nicht als Beweis einer normgerechten, vertrauenswürdigen Datei gelesen werden.