Zum Inhalt springen
TextArray1.41.0
100% lokal

security.txt Validator

Überprüfen Sie eine security.txt-Datei gegen RFC 9116 und listen Sie auf, was fehlt, ungültig oder veraltet ist.

Eingabe
Ausgabe
Verwandte Tools
Robots.txt-TesterneuEntwickler-Tools
Humans.txt-GeneratorEntwickler-Tools
SPF- und DMARC-CheckerneuEntwickler-Tools
i18n SchlüsseldiffEntwickler-Tools
TOML-zu-JSON-KonverterEntwickler-Tools
SQL zu JSONEntwickler-Tools
security.txt Validator
Fügen Sie den Inhalt einer security.txt-Datei ein — die eine sich unter /.well-known/security.txt befinden soll — und dieses Tool überprüft sie gegen RFC 9116, den Standard, der das Format definiert. Es meldet fehlende erforderliche Felder, Werte, die nicht analysiert werden können, und Feldnamen, die veraltet oder nicht erkannt werden, jeweils gebunden an die Zeile, aus der sie stammen.
RFC 9116 erfordert mindestens eine "Contact"-Zeile und genau eine "Expires"-Zeile; beide werden standardmäßig überprüft, zusammen mit dem "Expires"-Datum selbst — es muss ein vollständiger ISO 8601-Zeitstempel mit Zeitzone sein, und das Tool warnt, wenn dieses Datum bereits vergangen ist. Encryption, Policy, Hiring, Canonical und Acknowledgments sollen alle einen URI enthalten, daher flaggt das Tool eine bloße Domäne oder E-Mail ohne Schema. Es erfasst auch die veraltete britische Schreibweise "Acknowledgements" (RFC 9116 verwendet "Acknowledgments"), Felder, die aus früheren Entwürfen gelöscht wurden, wie "Disclosure", Feldnamen in falscher Groß-/Kleinschreibung, doppelte "Expires"- oder "Preferred-Languages"-Zeilen und Felder, die aus der herkömmlichen Lesereihenfolge fallen. Jede dieser Prüfungen kann einzeln deaktiviert werden.
Wechseln Sie die Ausgabe zwischen einer zeilenweisen Liste von Erkenntnissen und einer korrigierten Datei: Die festgelegte Version gruppiert erkannte Felder in die herkömmliche Reihenfolge, reduziert doppelte einzelne Felder auf das erste Vorkommen, korrigiert veraltete Feldnamen und behält alles bei, das nicht erkannt wird, anstatt es zu löschen. Zeilen ohne gültige "Field: value"-Form werden aufgerufen, anstatt sie zu erraten, und ein fehlendes "Contact" oder "Expires" wird mit einem Kommentar anstelle einer erfundenen Zeile vermerkt.
Alles läuft lokal in Ihrem Browser — die Datei, die Sie einfügen, oft eine echte, noch nicht veröffentlichte Sicherheitskontaktadresse, wird nie irgendwo hochgeladen. Kopieren Sie das Ergebnis, laden Sie es als .txt-Datei herunter, die zur Veröffentlichung bereit ist, oder geben Sie es zurück in die Eingabe, um eine andere Revision zu überprüfen.
Häufige Fragen
Was verlangt RFC 9116 tatsächlich?
Mindestens ein "Contact"-Feld und genau ein "Expires"-Feld mit einem gültigen RFC 3339-Datum und -Zeit. Alles andere — Encryption, Canonical, Preferred-Languages, Acknowledgments, Hiring und Policy — ist optional.
Warum wird mein "Expires"-Datum als ungültig gekennzeichnet?
RFC 9116 erfordert ein vollständiges Datum und Uhrzeit mit Zeitzone, wie 2027-01-01T00:00:00Z. Ein bloßes Datum wie 2027-01-01 oder ein nicht-ISO-Format erfüllt die Spezifikation nicht, auch wenn es wie ein Datum aussieht.
Was ändert die "Korrigierte Datei"?
Sie gruppiert erkannte Felder in die herkömmliche Lesereihenfolge, behält nur das erste Vorkommen eines Feldes bei, das singulär sein muss (Expires, Preferred-Languages), und korrigiert die veraltete Schreibweise "Acknowledgements" zu "Acknowledgments". Sie erfindet niemals einen Contact- oder Expires-Wert, der nicht bereits in Ihrer Datei vorhanden ist.
Abrufen der Live-security.txt von meiner Domain?
Nein. Fügen Sie den Dateiinhalt selbst ein — das Tool macht nie einen Netzwerkaufruf, daher kann es nicht bestätigen, was tatsächlich auf /.well-known/security.txt auf Ihrer Site veröffentlicht ist.
Wird meine security.txt-Datei irgendwo hochgeladen?
Nein. Die Validierung läuft vollständig in Ihrem Browser. Da diese Datei oft eine echte, noch nicht veröffentlichte Sicherheitskontaktadresse enthält, verlässt nichts, das Sie einfügen, jemals Ihr Gerät.