Security.txt-Prüfer
Validieren Sie Ihre security.txt-Datei gegen RFC 9116. Überprüft erforderliche Felder (Contact, Expires), optionale Felder (Encryption, Policy, Canonical), Ablaufstatus und HTTPS-Hosting. Erhalten Sie eine Gesundheitsbewertung und praktische Empfehlungen.
So verwenden Sie Security.txt-Prüfer
- 1Geben Sie einen Domänennamen ein (z.B. example.com).
- 2Das Tool ruft /.well-known/security.txt und /security.txt ab.
- 3Felder werden geparst und gegen RFC 9116-Anforderungen validiert.
- 4Überprüfen Sie die Gesundheitsbewertung, alle gefundenen Probleme und Empfehlungen.
ZenovayAnalytics
Sehen Sie, wer gerade auf Ihrer Seite ist.
- Besucher-Tracking in Echtzeit
- Datenschutz zuerst, kein Cookie-Banner
- In zwei Minuten eingerichtet
Verwandte Tools
Passwort-Generator
Generieren Sie starke, zufällige Passwörter mit anpassbarer Länge, Zeichen und Komplexität.Passwort-Stärke-Prüfer
Überprüfen Sie, wie stark Ihr Passwort ist. Erhalten Sie eine geschätzte Knackzeit und Verbesserungsvorschläge.HMAC-Generator
Generieren Sie HMAC-Signaturen mit SHA-256, SHA-384 oder SHA-512 mit der Web Crypto API.AES-Verschlüsselung/Entschlüsselung
Verschlüsseln und entschlüsseln Sie Text mit AES-GCM und PBKDF2-Schlüsselableitung. Läuft vollständig in Ihrem Browser.Häufig gestellte Fragen
Was ist security.txt und warum ist es wichtig?▾
security.txt ist eine Textdatei, die unter /.well-known/security.txt auf einer Website abgelegt wird und Sicherheitsforschern mitteilt, wie sie Schwachstellen verantwortungsbewusst melden können. Standardisiert in RFC 9116, enthaelt sie Kontaktinformationen, Offenlegungsrichtlinie, Verschlüsselungsschlüssel und ein Ablaufdatum. Ohne sie wissen Forscher möglicherweise nicht, wie sie Ihr Sicherheitsteam erreichen können, was dazu fuehren kann, dass Schwachstellen ungemeldet oder öffentlich bekannt gemacht werden.
Welche Felder sind in security.txt erforderlich?▾
RFC 9116 erfordert zwei Felder: (1) Contact: mindestens eine Kontaktmethode (mailto:, https:// oder tel:-URI) und (2) Expires: ein ISO-8601-Datum/Uhrzeit, wann diese Datei als veraltet gelten soll. Alle anderen Felder sind optional, aber dringend empfohlen: Encryption (PGP-Schlüssel-URL), Policy (URL der Offenlegungsrichtlinie), Canonical (die kanonische URL dieser Datei), Preferred-Languages, Acknowledgments, Hiring und CSAF.
Wo sollte security.txt abgelegt werden?▾
Der bevorzugte Ort gemaess RFC 9116 ist /.well-known/security.txt (z. B. https://example.com/.well-known/security.txt). Der alte Speicherort /security.txt wird auch für die Abwärtskompatibilitaet unterstützt. Die Datei muss über HTTPS bereitgestellt werden. Wenn beide Speicherorte vorhanden sind, hat /.well-known/security.txt Vorrang.
Wie lange sollte security.txt gueltig sein?▾
RFC 9116 empfiehlt, das Expires-Feld auf höchstens ein Jahr in der Zukunft zu setzen. Eine kuerzere Gueltigkeitsdauer (z. B. 90-180 Tage) erzwingt regelmäßige Überprüfungen und stellt sicher, dass Kontaktinformationen aktuell bleiben. Abgelaufene security.txt-Dateien werden behandelt, als waere keine Datei vorhanden. Viele Teams setzen es auf genau ein Jahr und erneuern es jaehrlich.
Sollte security.txt PGP-signiert sein?▾
PGP-Signierung ist optional, aber für Hochsicherheitsumgebungen empfohlen. Eine signierte security.txt ermöglicht es Forschern, zu verifizieren, dass die Datei nicht manipuliert wurde - ein Angreifer, der Ihren Webserver kompromittiert, könnte die security.txt sonst mit einer anderen Kontaktadresse ersetzen. Signieren Sie mit dem PGP-Schlüssel Ihres Sicherheitsteams und verlinken Sie den öffentlichen Schlüssel über das Encryption-Feld.