security.txt

Nach RFC 9116

Sicherheits-Kontakt-Datei nach RFC 9116. Ab September 2026 vom CRA gefordert.

Was ist das, und wann brauche ich es?

Was ist das?

Die security.txt ist eine kleine Textdatei nach RFC 9116, die im versteckten Pfad /.well-known/security.txt Ihrer Website liegt. Sie sagt Sicherheits- Forscherinnen und -Forschern auf einen Blick, an welche Adresse sie Schwachstellen melden können (Mail, PGP-Key, Web-Formular) - und in welchen Sprachen, mit welcher Antwortzeit, unter welcher Disclosure-Policy.

Ohne security.txt landen Meldungen entweder im allgemeinen Postfach (wo sie liegenbleiben) oder gar nicht (weil der Finder keine Adresse findet und resigniert). Mit security.txt bekommen Sie strukturierte, ernst gemeinte Reports.

Wann brauche ich das?

Direkt nützlich wenn Sie eine Web-Anwendung, eine Login-Maske, einen API-Endpunkt oder einen Online-Dienst betreiben - kurz gesagt: alles wo unsachgemäße Nutzung Daten abgreifen oder Schaden anrichten kann.

Ab September 2026 Pflicht für Hersteller digitaler Produkte mit Marktzugang in der EU. Der EU Cyber Resilience Act (CRA) verlangt einen veröffentlichten, koordinierten Disclosure-Kanal - security.txt ist der einfachste Weg, diese Pflicht zu erfüllen.

Sinnvolle nächste Schritte

Contact (eine Adresse pro Zeile, Pflicht) Akzeptiert mailto:, https: oder tel: URIs. Eine Pseudo-Adresse wie "abuse@" reicht nicht, RFC 9116 verlangt einen tatsächlich erreichbaren Kanal für Sicherheits-Meldungen. Expires (ISO-8601, max. 1 Jahr) Pflichtfeld seit RFC 9116. Datum mit Zeitzone (z. B. 2027-05-17T06:39:46Z); maximal ein Jahr in der Zukunft, danach gilt die Datei als abgelaufen und Scanner ignorieren sie.

Preferred-Languages BCP-47-Sprach-Codes (z. B. de, en) für Sprachen, in denen Sie Sicherheits-Meldungen entgegennehmen. Komma-getrennt, Reihenfolge = Präferenz. Canonical-URL HTTPS-URL der security.txt selbst. Schützt vor MITM-Manipulation, weil Scanner nur die kanonische URL als „echt" akzeptieren. Wenn leer, akzeptieren Scanner die abgerufene URL. Encryption Optional, URI zu einem OpenPGP-Schlüssel: https:-URL, dns:-OPENPGPKEY-Record oder openpgp4fpr:-Fingerprint. Den Schlüssel selbst NICHT einfügen - nur die URI. Acknowledgments-URL Optional, Öffentliche Seite, auf der Sie Sicherheitsforscher namentlich danken („Hall of Fame"). Policy-URL Optional, ihre Disclosure-Policy: Was im Scope ist, wie lange Sie für Antworten brauchen, welche Test-Methoden erlaubt sind. Reduziert Reibung mit Findern. Hiring-URL Karriere-Seite mit offenen Security-Stellen. Optional, aber ein netter Signal-Boost für aktive Security-Engineering-Teams.

/.well-known/security.txt nach RFC 9116

Herunterladen

# security.txt per RFC 9116
# Host under /.well-known/security.txt with Content-Type: text/plain; charset=utf-8
# Created with Dernium Webtools

Contact: mailto:security@example.com
Expires: 2027-07-03T17:59:03Z
Preferred-Languages: de, en

Deployment

Die Datei muss unter /.well-known/security.txt mit Content-Type text/plain; charset=utf-8 erreichbar sein, sowohl unter https als auch unter www-Variante. Optional zusätzlich unter dem Root-Pfad (/security.txt) als Legacy-Fallback.

Empfehlung: Vorab als PGP/Inline signieren (RFC 9116 § 3.3), damit Angreifer den Datei-Inhalt nicht in einem MITM-Szenario manipulieren können. Tools wie gpg --clearsign erzeugen das Format.

Bestehende security.txt einer Domain prüfen

Holt /.well-known/security.txt der angegebenen Domain (und Root-Fallback) und prüft die Felder gegen RFC 9116.

Probieren mit:

Server-Pfad: Diese Inspektion läuft NICHT browser-lokal. Wir holen den DNS-Record bzw. die HTTPS-Antwort über unseren Server. Wir loggen weder die abgefragte Domain noch das Ergebnis. 12 Anfragen pro Minute pro IPv4-Adresse bzw. IPv6-/64-Subnet.