Teil 5 der Serie „EU Web Security: In 10 Schritten zum besseren Rating"
Warum security.txt
Ein Sicherheitsforscher findet eine Schwachstelle auf Ihrer Website. Wen kontaktiert er?
Ohne security.txt: Er sucht im Impressum, findet info@, schreibt eine Mail. Die landet beim Marketing, wird als Spam gelöscht oder ignoriert. Die Schwachstelle bleibt offen.
Mit security.txt: Er ruft /.well-known/security.txt auf, findet den Security-Kontakt, den PGP-Schlüssel und die Disclosure-Policy. Die Meldung landet sofort beim richtigen Team.
Adoptionsrate in der EU: 2,8%. Und trotzdem: Websites mit security.txt scoren im Schnitt 31% besser als solche ohne.
Die Korrelation
| Metrik | MIT security.txt | OHNE | Faktor |
|---|---|---|---|
| Composite Score | 55 | 42 | +31% |
| HSTS | 72% | 26% | 2,8× |
| CSP | 47% | 10% | 4,7× |
| Note F | 6% | 44% | 7× weniger |
security.txt ist kein Allheilmittel. Aber wer sich die Mühe macht, es einzurichten, hat meistens den Rest auch im Griff.
So richten Sie security.txt ein
Schritt 1: Datei erstellen
Erstellen Sie /.well-known/security.txt auf Ihrem Webserver:
Contact: mailto:security@ihre-domain.de
Expires: 2027-04-13T00:00:00.000Z
Preferred-Languages: de, en
Pflichtfelder (RFC 9116):
- Contact: — E-Mail-Adresse oder URL für Sicherheitsmeldungen
- Expires: — Ablaufdatum (max. 1 Jahr in der Zukunft)
Optionale Felder:
- Encryption: — PGP-Schlüssel für verschlüsselte Meldungen
- Acknowledgments: — Hall of Fame für verantwortungsvolle Melder
- Canonical: — kanonische URL der Datei
- Policy: — Link zu Ihrer Vulnerability Disclosure Policy
- Hiring: — Link zu Security-Stellenangeboten
Schritt 2: Erreichbar machen
Die Datei muss unter https://ihre-domain.de/.well-known/security.txt erreichbar sein. Bei den meisten Setups:
Nginx:
location = /.well-known/security.txt {
alias /var/www/ihre-domain.de/security.txt;
}
Apache: Die Datei direkt in /.well-known/ ablegen reicht.
WordPress: Plugin "WP Security.txt" oder manuell in .well-known/ im Webroot.
Schritt 3: PGP-Schlüssel bereitstellen (empfohlen)
Contact: mailto:security@ihre-domain.de
Encryption: https://ihre-domain.de/.well-known/pgp-key.txt
Expires: 2027-04-13T00:00:00.000Z
Das BSI empfiehlt explizit die Verschlüsselungsoption, damit Sicherheitsmelder vertrauliche Details geschützt übermitteln können.
Branchen-Adoption
| Branche | Adoption | Avg Score mit | Avg Score ohne |
|---|---|---|---|
| Banking | 23,9% | 69 | 55 |
| E-Commerce | 15,6% | 64 | 53 |
| Education | 8,1% | 53 | 42 |
| Tech | 5,3% | 63 | 45 |
| Healthcare | 2,0% | 58 | 42 |
| Hospitality | 1,1% | 51 | 40 |
Banking führt — fast jede vierte Bank hat security.txt. Hospitality (Hotels, Gastronomie) liegt bei 1,1%.
Regulatorischer Kontext
- NIS2 Art. 21(2)(e) verlangt explizit „Vulnerability Handling and Disclosure" — security.txt ist der standardisierte Weg dafür
- CRA Art. 14 — koordinierte Vulnerability Disclosure wird ab Dezember 2027 Pflicht für Hersteller digitaler Produkte
- BSI empfiehlt security.txt explizit und setzt es auf bsi.bund.de ein
- ENISA listet security.txt als Best Practice für Vulnerability Disclosure
Häufige Fehler
1. Expires vergessen. Ohne Expires ist die Datei laut RFC 9116 ungültig. Setzen Sie es auf 1 Jahr in die Zukunft und erinnern Sie sich, es zu aktualisieren.
2. HTTP statt HTTPS. Die Datei muss über HTTPS erreichbar sein — eine unverschlüsselte security.txt könnte manipuliert werden.
3. info@ als Kontakt. Contact: mailto:info@... landet beim Marketing. Richten Sie eine dedizierte security@-Adresse ein, die bei einem Sicherheitsverantwortlichen ankommt.
Prüfen Sie Ihre security.txt
Nächste Woche in Teil 6: DKIM — warum nur 31% der EU-Domains ihre E-Mails signieren.