security.txt auf Hetzner einrichten
Schritt-für-Schritt-Anleitung: security.txt nach RFC 9116 auf Ihrem Hetzner Cloud Server erstellen — mit vollständigem Dateiinhalt, Nginx- und Apache-Konfiguration und Verifizierung.
security.txt auf Hetzner
Die security.txt ist eine standardisierte Textdatei unter /.well-known/security.txt, die Sicherheitsforschern einen Kontaktweg bietet, wenn sie eine Schwachstelle auf Ihrer Website entdecken. Ohne diese Datei wissen Forscher oft nicht, an wen sie sich wenden sollen — und melden die Schwachstelle gar nicht oder veröffentlichen sie direkt.
Im Wolf-Agents Web Security Check bringt security.txt 2 von 166 Punkten. Der Aufwand ist minimal — die Datei besteht aus wenigen Zeilen Plaintext — aber der Nutzen ist erheblich: Sie etablieren einen professionellen Responsible-Disclosure-Prozess. Auf einem Hetzner Cloud Server erstellen Sie die Datei direkt im Dateisystem und konfigurieren den Webserver für die korrekte Auslieferung.
security.txt erstellen
Erstellen Sie das Verzeichnis /.well-known/ im Document Root Ihres Hetzner Servers und legen Sie die Datei security.txt darin an. Die Pflichtfelder nach RFC 9116 sind Contact und Expires. Verwenden Sie eine dedizierte Sicherheits-E-Mail-Adresse — nicht die allgemeine info@-Adresse.
# /.well-known/security.txt
# RFC 9116 — https://securitytxt.org/
Contact: mailto:security@ihre-domain.de
Expires: 2027-03-27T00:00:00.000Z
Preferred-Languages: de, en
Canonical: https://ihre-domain.de/.well-known/security.txt
# Optional: Encryption (PGP Public Key)
# Encryption: https://ihre-domain.de/.well-known/pgp-key.txt
# Optional: Policy (Responsible Disclosure)
# Policy: https://ihre-domain.de/security-policy
# Optional: Hiring
# Hiring: https://ihre-domain.de/jobsRFC 9116 schreibt das Expires-Feld vor. Setzen Sie es maximal 1 Jahr in die Zukunft. Richten Sie sich eine Erinnerung ein, um das Datum rechtzeitig zu aktualisieren. Ein abgelaufenes Expires-Datum signalisiert Forschern, dass die Datei möglicherweise veraltet und der Kontakt nicht mehr aktuell ist.
Webserver für die Auslieferung konfigurieren
Die Datei muss unter der exakten URL https://ihre-domain.de/.well-known/security.txt erreichbar sein. In Nginx benötigen Sie einen expliziten location-Block, weil die Standard-Konfiguration /.well-known/ oft nicht abdeckt. In Apache wird die Datei meist automatisch ausgeliefert.
# /etc/nginx/snippets/well-known.conf
# Include in jedem server{}-Block:
# include snippets/well-known.conf;
location = /.well-known/security.txt {
alias /var/www/html/.well-known/security.txt;
default_type "text/plain; charset=utf-8";
add_header Cache-Control "public, max-age=86400" always;
}# /etc/apache2/conf-available/security-txt.conf
# Die Datei liegt im Document Root:
# /var/www/html/.well-known/security.txt
# Apache liefert Dateien unter /.well-known/
# automatisch aus, wenn sie existieren.
# Falls .well-known blockiert ist:
<Directory /var/www/html/.well-known>
Require all granted
Options -Indexes
</Directory>
# Korrekter Content-Type
<Files "security.txt">
ForceType "text/plain; charset=utf-8"
</Files>Erreichbarkeit verifizieren
Rufen Sie die Datei per curl ab. Der HTTP-Statuscode muss 200 sein, der Content-Type text/plain, und der Inhalt muss vollständig angezeigt werden.
# security.txt abrufen
curl https://ihre-domain.de/.well-known/security.txt
# Erwartete Ausgabe: Der vollständige Dateiinhalt
# Contact: mailto:security@ihre-domain.de
# Expires: 2027-03-27T00:00:00.000Z
# ...
# HTTP-Status und Content-Type prüfen
curl -sI https://ihre-domain.de/.well-known/security.txt
# HTTP/2 200
# content-type: text/plain; charset=utf-8Häufige Fehler bei security.txt auf Hetzner
Abgelaufenes Expires-Datum
Das Expires-Feld wird bei der Ersteinrichtung gesetzt und dann vergessen. Setzen Sie sich einen jährlichen Kalender-Reminder. Der Wolf-Agents Web Security Check warnt Sie, wenn das Datum abgelaufen ist. Ein abgelaufenes Expires ist der häufigste Fehler bei security.txt.
Fehlender Nginx-Location-Block
Auf Hetzner-Servern mit Nginx und einer Anwendung (Node.js, PHP-FPM) wird häufig alles an das Backend weitergeleitet. Die statische Datei unter /.well-known/security.txt wird dann vom Backend statt von Nginx ausgeliefert — und gibt oft einen 404 zurück. Lösung: Ein expliziter location = /.well-known/security.txt-Block vor dem Backend-Proxy.
PGP-Signatur empfohlen, aber optional
RFC 9116 empfiehlt, die security.txt mit PGP zu signieren. Das ist optional, erhöht aber die Vertrauenswürdigkeit. Wenn Sie signieren, verlinken Sie den öffentlichen Schlüssel im Encryption-Feld und stellen Sie sicher, dass die Signatur beim Datei-Update erneuert wird.
Compliance-Relevanz
RFC 9116 standardisiert die security.txt als offiziellen Kontaktweg für Sicherheitsforscher. Das BSI empfiehlt die Einrichtung einer security.txt explizit als Best Practice für Responsible Disclosure. Auch wenn der Header nur 2 Punkte im Scoring bringt, signalisiert er professionelles Sicherheitsmanagement — und kann im Ernstfall dazu führen, dass eine Schwachstelle gemeldet statt ausgenutzt wird.
Wie steht Ihre Domain bei security.txt?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.