Feature-Request: security.txt (RFC 9116) automatisch bei Domain-Anlage erzeugen

[gseilheimer]

Anlass: Die BSI-Pressemitteilung vom 06.08.2026 weist darauf hin, dass nur ca. 1,8 % der deutschen Website-Betreiber eine security.txt (RFC 9116) bereitstellen. Da KeyHelp bereits pro Domain sowohl die Kontaktdaten als auch eine automatische Webroot-Grundausstattung (Index-Seite mit Bulma-CSS-Framework) anlegt, wäre eine automatische security.txt-Erstellung ein sehr kleiner Zusatzaufwand mit spürbarem Sicherheitsgewinn für alle KeyHelp-Kunden.

Vorschlag

Bei Anlage einer neuen Domain (optional auch nachträglich je Domain aktivierbar, z. B. per Checkbox in den Domain-Einstellungen) legt KeyHelp automatisch eine Datei <webroot>/.well-known/security.txt an — analog zur bereits heute automatisch erzeugten Index-Seite, unabhängig davon, welches CMS/Framework später auf der Domain betrieben wird.

Warum das mit vorhandenen Daten machbar ist

• Contact: kann direkt aus der ohnehin in KeyHelp hinterlegten Kontakt-/Admin-E-Mail der Domain befüllt werden — keine zusätzliche Eingabe durch den Kunden nötig.

• Canonical: ergibt sich automatisch aus dem Domainnamen (https://<domain>/.well-known/security.txt).

• Expires: Pflichtfeld nach RFC 9116 — Vorschlag: automatisch +1 Jahr ab Erstellung, mit demselben Erinnerungs-/Auto-Verlängerungsmechanismus, der bereits für die Let's-Encrypt-Zertifikatserneuerung existiert (damit die Datei nicht unbemerkt „abläuft").

• Preferred-Languages: optional konfigurierbar, Standardwert z. B. de, en.

• Die Datei ist eine reine statische Textdatei im Webroot (chmod 644) — keine Interferenz mit WordPress, Shop-Systemen oder sonstigen auf der Domain laufenden Anwendungen.

Minimal-Umsetzung (Vorschlag)

• Checkbox „security.txt automatisch erstellen und aktuell halten" — global in den Account-Einstellungen oder je Domain.
  Bei Aktivierung: einmalige Erzeugung der Datei mit obigen Feldern.

• Jährliche automatische Erneuerung des Expires-Datums (Cron, analog SSL-Erneuerung), optional mit Info-Mail an den Kunden.

• Kein Pflicht-Feature — für Kunden, die eine eigene security.txt pflegen möchten, per Checkbox deaktivierbar/überschreibbar (keine Konflikte mit bestehenden Dateien erzeugen).

Nutzen

Erhöht die BSI-konforme Basisabsicherung für alle KeyHelp-Kunden mit minimalem Aufwand, da sowohl die benötigten Kontaktdaten als auch der Mechanismus zur automatischen Webroot-Erstellung in KeyHelp bereits vorhanden sind.

[Jolinar]

Grundsätzlich eine interessante Idee, ich möchte jedoch ein paar Sachen anmerken...


Zunächst einmal:

Anlass: Die BSI-Pressemitteilung vom 06.08.2026 weist darauf hin, dass nur ca. 1,8 % der deutschen Website-Betreiber eine security.txt (RFC 9116) bereitstellen.

RFC9116 ist noch kein Standard, bisher ist die RFC nur als „Informational“ getaggt.


Die gewünschte Implementierung klingt zunächst einfach, aber es gibt IMHO ein paar Punkte, die brücksichtigt werden sollten:

• Man darf nicht davon ausgehen, daß die allgemeine Domain- oder Admin-E-Mail auch automatisch ein geeigneter Security-Kontakt sind
• Wie werden multiple Kontakte sinnvoll implementiert
• Wie wird eine userdefinierte security.txt gehandelt
• Expires sollte nicht unkontrolliert automatisch verlängert werden, hier müßte ein valider Mechanismus etabliert werden
• Inwieweit sind Policy und Encryption als optionale Felder interessant
• Sollte Preferred-Languages zB. mit de, en sinnvoll vorbelegt werden
• Die Datei sollte optional pro Domain aktiviert werden können und für User mit eigener Security-Policy vollständig deaktivierbar sein

[Blubby]

Grundsätzlich eine interessante Idee, ich möchte jedoch ein paar Sachen anmerken...

Ich halte das für eine schlechte Idee. ein Großteil des Webtraffics wird eh schon von Scrapern und Spammern verursacht, denen noch mehr (gute) und leicht abrufbare Daten zu liefern kann nicht der Weisheit letzter Schluss sein.

In den paar Einzelfällen wo sowas mal nützlich sein könnte kann man sie auch mal per Hand anlegen, ändern tut die sich ja eh kaum.

[Tobi]

Also ich will nur mal anmerken, dass wir KeyHelp als Agentur-Server verwenden.
Unsere Kunden haben i.d.R. gar keinen Zugang und die Kontaktdaten sind auch nicht hinterlegt.
Dann gibt es auch Sammel-Accounts mit Domains unterschiedlicher Inhaber.

Lange Rede kurzer Sinn:
Der angedachte Automatismus würde uns mehr Arbeit verursachen als Nutzen bringen.