security.txt: Vulnerability Disclosure einrichten
Die security.txt nach RFC 9116 gibt Sicherheitsforschern einen standardisierten Kontaktweg, um Schwachstellen verantwortungsvoll zu melden — statt sie öffentlich zu machen.
Warum security.txt?
Die security.txt ist eine standardisierte Textdatei (RFC 9116) unter /.well-known/security.txt, die Sicherheitsforschern mitteilt, wie sie Schwachstellen verantwortungsvoll melden können. Ohne diese Datei landen Sicherheitsmeldungen in generischen Kontaktformularen oder werden öffentlich gemacht — beides kann für Ihr Unternehmen teuer werden.
2016 verlor Uber 57 Millionen Nutzerdaten, weil Hacker keinen offiziellen Melde-Kanal fanden und stattdessen das Unternehmen erpressten. Bug-Bounty-Programme mit security.txt-Verweis haben bei Google, der Deutschen Telekom und Microsoft nachweislich zu mehr verantwortungsvollen Meldungen geführt. Der Wolf-Agents Web Security Check prüft die security.txt als Teil der 166 Prüfpunkte.
Was enthält security.txt?
Die security.txt nach RFC 9116 ist eine einfache Textdatei mit standardisierten Feldern, die Sicherheitsforschern alle nötigen Informationen zur verantwortungsvollen Schwachstellenmeldung gibt. Zwei Felder sind Pflicht, sechs weitere sind optional.
Pflichtfelder
| Feld | Beschreibung | Beispiel |
|---|---|---|
Contact | Kontaktmöglichkeit für Sicherheitsmeldungen | mailto:security@example.com |
Expires | Ablaufdatum der Datei (ISO 8601) | 2027-01-31T23:59:59.000Z |
Optionale Felder
| Feld | Beschreibung | Beispiel |
|---|---|---|
Encryption | PGP-Schlüssel für verschlüsselte Kommunikation | https://example.com/pgp-key.txt |
Acknowledgments | Seite mit Danksagungen (Hall of Fame) | https://example.com/hall-of-fame |
Preferred-Languages | Bevorzugte Sprachen | de, en |
Canonical | Kanonische URL der security.txt | https://example.com/.well-known/security.txt |
Policy | Link zur Security Policy | https://example.com/security-policy |
Hiring | Link zu Security-Stellenangeboten | https://example.com/jobs/security |
# Unsere Security-Kontaktinformationen
# Letzte Aktualisierung: 2026-03-18
Contact: mailto:security@example.com
Contact: https://example.com/security-contact
Expires: 2027-01-31T23:59:59.000Z
# Optionale Felder
Encryption: https://example.com/.well-known/pgp-key.txt
Acknowledgments: https://example.com/security/hall-of-fame
Preferred-Languages: de, en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policy
Hiring: https://example.com/careers/securitysecurity.txt bereitstellen
Die Implementierung einer security.txt ist in wenigen Minuten erledigt und birgt kein technisches Risiko. Die Datei muss unter /.well-known/security.txt erreichbar sein und mit dem Content-Type text/plain; charset=utf-8 ausgeliefert werden. Je nach Stack unterscheidet sich der Weg dorthin.
Nginx
# Zugriff auf .well-known erlauben
location = /.well-known/security.txt {
alias /var/www/html/.well-known/security.txt;
default_type text/plain;
charset utf-8;
}Apache
# .well-known-Zugriff erlauben
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^.well-known/ - [L]
</IfModule>Regulatorische Zuordnung
Die security.txt ist nicht in jeder Regulierung explizit vorgeschrieben, unterstützt aber nachweisbar die geforderte Vulnerability-Disclosure-Praxis. Sie bildet einen dokumentierbaren Baustein für Schwachstellenmanagement und Incident Response.
| Regulierung | Referenz | Bezug |
|---|---|---|
| NIS2 | Art. 23 | Meldepflichten bei Sicherheitsvorfällen |
| ISO 27001 | A.8.8 | Management of technical vulnerabilities |
| BSI IT-Grundschutz | DER.2.1 | Behandlung von Sicherheitsvorfällen |
| CRA | Art. 14 | Vulnerability Disclosure für digitale Produkte |
Wie steht Ihre Domain bei security.txt?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.
Häufig gestellte Fragen
Was ist security.txt?
security.txt ist eine standardisierte Textdatei nach RFC 9116, die Sicherheitsforschern mitteilt, wie sie Schwachstellen auf Ihrer Website verantwortungsvoll melden können. Sie wird unter /.well-known/security.txt bereitgestellt und enthält mindestens ein Contact- und ein Expires-Feld.
Wo muss die Datei liegen?
Die security.txt muss unter /.well-known/security.txt erreichbar sein — das ist der bevorzugte Pfad laut RFC 9116. Viele automatisierte Tools und Scanner suchen ausschließlich an dieser Stelle. Ein Fallback unter /security.txt ist zulässig, aber nicht empfohlen.
Welche Felder sind Pflicht?
RFC 9116 schreibt zwei Pflichtfelder vor: Contact (z.B. mailto:security@example.com) und Expires (Ablaufdatum im ISO-8601-Format). Optionale Felder sind Encryption, Acknowledgments, Preferred-Languages, Canonical, Policy und Hiring.
Wie oft muss ich das Expires-Datum aktualisieren?
Das Expires-Datum sollte maximal ein Jahr in der Zukunft liegen. Planen Sie eine regelmäßige Aktualisierung ein — idealerweise halbjährlich. Ein abgelaufenes Expires-Datum signalisiert Sicherheitsforschern, dass die Kontaktdaten möglicherweise nicht mehr aktuell sind.
Brauche ich security.txt für NIS2-Compliance?
security.txt ist in NIS2 nicht explizit vorgeschrieben, unterstützt aber die Meldepflichten nach Art. 23 und die geforderte Vulnerability-Disclosure-Praxis. In Kombination mit ISO 27001 A.8.8 und BSI IT-Grundschutz DER.2.1 bildet sie einen nachweisbaren Baustein für Ihr Schwachstellenmanagement.
Was passiert, wenn jemand eine Schwachstelle über security.txt meldet?
Sie sollten innerhalb von 24-48 Stunden eine Empfangsbestätigung senden, die Schwachstelle bewerten (Triage innerhalb von 5 Werktagen), regelmäßige Status-Updates geben und den Fix koordiniert veröffentlichen. Eine dokumentierte Vulnerability Disclosure Policy (VDP) definiert den gesamten Prozess verbindlich.