security.txt bei DomainWarn hosten
Eine security.txt (RFC 9116) sagt Sicherheitsforschern, wo sie eine gefundene Lücke melden: unter https://kunde.de/.well-known/security.txt, mit mindestens einem Kontakt und einem Ablaufdatum (Expires). Am Ablaufdatum verwaisen die meisten Dateien – einmal abgelegt, laufen sie nach spätestens einem Jahr ab, und Forscher ignorieren sie.
DomainWarn erzeugt und pflegt die Datei. Im Reiter „Website“ einer Domain trägst du unter „security.txt“ die Kontakte ein (E-Mail, Telefon oder die HTTPS-Adresse eines Meldeformulars, höchstens zehn), dazu optional Schlüssel (Encryption), Richtlinie (Policy), Danksagungen (Acknowledgments), Stellenangebote (Hiring) und Sprachen (Preferred-Languages). Canonical und Expires setzt DomainWarn selbst: Canonical ist die Adresse beim Kunden, Expires liegt stets 180 Tage voraus und wird täglich neu gesetzt. Solange DomainWarn ausliefert, läuft die Datei nie ab.
Die Datei liegt unter einer festen, nicht erratbaren Adresse auf der Website von DomainWarn. Unter der Domain des Kunden kommt sie am besten direkt an: Der Webserver des Kunden holt sie dort ab und gibt sie unter /.well-known/security.txt mit Status 200 aus (Proxy) – Forscher sehen sie ohne Umweg unter der Adresse, die sie abgefragt haben. Wo kein Proxy-Modul zur Verfügung steht oder nur die .htaccess bearbeitet werden kann, leitet der Kunde den Pfad stattdessen mit 302 weiter; RFC 9116 erlaubt den Abruf über eine Weiterleitung. Das Dashboard nennt für Apache, nginx und Caddy die fertigen Zeilen für beide Wege und den Filterausdruck für eine Redirect Rule bei Cloudflare; bei WordPress und Shopware übernimmt das Plugin bzw. die Erweiterung die Auslieferung (siehe unten).
# nginx: einmal im http-Kontext, außerhalb von server
proxy_cache_path /var/cache/nginx/security-txt levels=1 keys_zone=security_txt:1m max_size=1m inactive=1d;
# nginx: im server-Block der Domain
location = /.well-known/security.txt {
proxy_pass https://domainwarn.com/security-txt/k7x2…/security.txt;
proxy_ssl_server_name on;
proxy_ssl_verify on;
proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
proxy_set_header Host domainwarn.com;
proxy_set_header Cookie "";
proxy_set_header Authorization "";
proxy_hide_header Strict-Transport-Security;
proxy_ignore_headers Cache-Control Expires;
proxy_cache security_txt;
proxy_cache_valid 200 10m;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
}
# Alternative ohne Proxy – Apache: ganz oben in die .htaccess, vor die Regeln von WordPress oder Shopware
RewriteEngine On
RewriteRule ^\.well-known/security\.txt$ https://domainwarn.com/security-txt/k7x2…/security.txt [R=302,L]Beim Proxy zählen drei Dinge: Host-Header und SNI nennen domainwarn.com (sonst kommt die Anfrage nicht an), Cookies und Authorization der Besucher bleiben beim Kunden, und die HSTS-Kopfzeile von DomainWarn wird nicht durchgereicht. Ein kurzer Zwischenspeicher (zehn Minuten) hält die Last klein und überbrückt einen Ausfall von DomainWarn mit der zuletzt geholten Fassung. Die Adresse bleibt bei jeder Änderung gleich, auch beim Aus- und Wiedereinschalten – Proxy oder Weiterleitung werden nur einmal eingerichtet. Abgeschaltet, bei gelöschter Domain oder gesperrter Organisation antwortet sie mit 404. Werte mit Zeilenumbrüchen oder Steuerzeichen nimmt DomainWarn nicht an: Jede Angabe ist genau eine Zeile der Datei. Wer die Datei lieber selbst ablegt, kopiert sie aus dem Dashboard; dann steht Expires darin fest, und der Check warnt 30 Tage vor dem Ablauf.
Liegt die Zone bei Cloudflare und ist sie über eine Integration verbunden, richtet ein Klick auf „Mit Cloudflare einrichten“ einen Worker ein, der die Datei direkt unter der Domain des Kunden ausliefert: https://kunde.de/.well-known/security.txt antwortet mit 200 und dem Inhalt der Datei, ohne Weiterleitung. Der Worker holt die Datei bei DomainWarn, hält sie eine Stunde im Cache von Cloudflare und antwortet bei einem Ausfall mit 502 statt einer HTML-Seite. Dafür braucht das Token zusätzlich „Konto → Workers Scripts → Edit“ (Kontoressourcen: das Konto mit den Kundenzonen) und „Zone → Workers Routes → Edit“. DomainWarn legt je Domain ein eigenes Skript domainwarn-security-txt-… mit einer Route genau auf diesen Pfad an (für die Domain und – bei überwachter www-Website – für www) und ändert nur diese; fremde Worker und Routen bleiben unberührt, eine fremde Route für denselben Pfad nennt die Vorschau. Workers gibt es auch im Free-Tarif von Cloudflare, die Route trifft nur den Abruf der security.txt.
Fehlen dem Token die Rechte für Worker, richtet DomainWarn die Weiterleitung als Redirect Rule ein (Single Redirects, 302) und sagt in der Karte, welche Rechte fehlen; dafür braucht das Token „Zone → Single Redirect → Edit“. Die Regel trägt die Kennung domainwarn_security_txt, DomainWarn ändert nur sie – alle anderen Regeln bleiben, wie und wo sie sind. Kommen die Worker-Rechte später dazu, stellt ein Klick auf den Worker um und schaltet die eigene Regel ab, weil Cloudflare Weiterleitungsregeln vor Workern auswertet. Beim Abschalten der security.txt bleiben Worker bzw. Regel stehen und antworten mit 404. Beides greift nur für Hostnamen, die über den Cloudflare-Proxy laufen (orange Wolke). Reine DNS-Anbieter (Hetzner DNS, IONOS, netcup, INWX, OVHcloud, Route 53, deSEC, autoDNS) beantworten kein HTTP; dort bleibt es bei den Zeilen für den Webserver.
Der security.txt-Check prüft anschließend von außen, ob die Datei ankommt. Über die Weiterleitung landet er bei der Adresse von DomainWarn; direkt ausgeliefert erkennt er die Datei an der Kommentarzeile # domainwarn-id: …, einer Kennung, die aus dem Token abgeleitet ist, es aber nicht verrät. Canonical beim Kunden zählt nicht als Abweichung. Die Karte im Dashboard zeigt das Ergebnis der letzten Prüfung: aktiv (direkt oder über die Weiterleitung), noch keine Datei gefunden, eine andere security.txt – oder eine veraltete Kopie, wenn die Datei mit unserer Kennung, aber mit altem Expires ausgeliefert wird, also einmal kopiert und nicht mehr nachgezogen.
Siehe auch: Was geprüft wird