Eingaben
Beispiel
https://example.com/.well-known/security.txt -> Contact, Expires, Canonical, Encryption, Policy, Hiring und Preferred-Languages.
security.txt-Validator/Generator
Validiert RFC-9116-Kontakte zur Schwachstellenmeldung, Ablaufdatum, Canonical-URL, Policy, Verschlüsselung und Hiring-Felder.
Nutze es, um eine Kontaktdatei für Schwachstellenmeldungen vor Veröffentlichung unter /.well-known/security.txt zu validieren.
Die Datei, die entscheidet, ob Researcher dich erreichen
Wenn ein externer Researcher eine Schwachstelle in deiner Infrastruktur findet, entscheiden die nächsten dreißig Minuten darüber, ob du einen verantwortungsvollen Report bekommst oder einen öffentlichen Write-up. Genau für diesen Moment gibt es security.txt nach RFC 9116: eine maschinenlesbare Datei an einer Well-known-URL, die sagt, wer zu kontaktieren ist, in welcher Sprache, unter welcher Policy und mit welchem PGP-Schlüssel verschlüsselt werden soll. Es ist eine der billigsten Sicherheitsmaßnahmen überhaupt — und eine der am häufigsten verpatzten.
Der häufigste Fehler ist das stille Ablaufen. Der RFC macht das Expires-Feld verpflichtend, gerade weil veraltete Kontaktdateien die Regel waren — und eine abgelaufene security.txt liest sich wie eine unbetreute Sicherheitsfunktion. Fehler Nummer zwei sind unerreichbare oder falsch platzierte Dateien: nur im Root statt unter /.well-known/, auf eine Marketing-Seite umgeleitet oder von einer übereifrigen WAF-Regel blockiert. Dieses Tool validiert eine geholte oder eingefügte Datei gegen die Feldregeln des RFC und generiert einen sauberen Entwurf, wenn du bei null anfängst.
Validieren, generieren und signieren in der richtigen Reihenfolge
Bei einem bestehenden Deployment: Hole die Live-Datei und lies die Befunde nach Schweregrad — zuerst ein fehlendes oder überschrittenes Expires, dann fehlerhafte Contact-Einträge, danach Canonical-Abweichungen. Contact-Einträge gelten in Präferenzreihenfolge: Das tatsächlich überwachte Postfach gehört nach oben, und sowohl mailto- als auch https-URIs haben Syntaxregeln, die der RFC streng auslegt.
Beim Generieren: Widersteh der Versuchung, jedes optionale Feld zu befüllen. Eine kurze, ehrliche Datei — Contact, Expires innerhalb eines Jahres, Canonical, Encryption falls ihr PGP-Mail verarbeiten könnt — schlägt eine lange aspirative. Wenn du signierst, wird das Canonical-Feld tragend: Es bindet die Signatur an die URL und muss exakt der Auslieferungsadresse entsprechen. Signiert wird lokal mit deinem eigenen Schlüssel; die Seite liefert die gpg-Kommandos, fasst aber privates Schlüsselmaterial nie an.
Was lokal bleibt und was das Tool nicht übernimmt
Eingefügter Inhalt bleibt im Browser, URL-Abrufe laufen über den Same-Origin-Helfer gegen öffentliche Hosts. Der Validator beweist Struktur: dass Felder parsen, Daten RFC-3339-konform sind und URIs wohlgeformt. Er kann nicht beweisen, dass jemand das Postfach liest, dass der unter Encryption verlinkte PGP-Schlüssel der ist, mit dem euer Team tatsächlich entschlüsseln kann, oder dass euer Prozess in vernünftiger Zeit antwortet. Syntax ist die Eintrittskarte; der Prozess dahinter gehört dir.
Häufige Fragen
Warum ist Expires Pflicht, wo doch kaum eine Metadatei ein Ablaufdatum hat?
Weil Kontaktdaten lautlos verrotten. Ein erzwungenes Ablaufdatum erzwingt die periodische Durchsicht, und Researcher werten ein aktuelles Datum als Zeichen, dass den Prozess noch jemand besitzt. Halte die Gültigkeit bei maximal einem Jahr und erneuere sie wie ein Zertifikat.
Gehört die Datei unter /.well-known/ oder in den Site-Root?
Der kanonische Ort ist /.well-known/security.txt. Zusätzlich unter /security.txt auszuliefern ist verbreitete Legacy-Höflichkeit. Wer beides ausliefert, hält die Kopien byteidentisch — auseinanderlaufende Versionen sind schlimmer als eine fehlende Legacy-Kopie.
Lohnt sich das Signieren angesichts des Betriebsaufwands?
Wenn du ohnehin einen PGP-Schlüssel unter Encryption listest, ist Signieren konsequent und billig: Ein Researcher kann prüfen, dass die Kontaktdaten vom Schlüsselinhaber stammen. Hat euer Team keinen PGP-Workflow, ist eine unsignierte, aber aktuelle und korrekte Datei deutlich besser als eine signierte veraltete.
Kann ich mehrere Contact-Einträge angeben?
Ja, und die Reihenfolge zählt: Frühere Einträge gelten laut RFC als bevorzugt. Bewährt ist ein überwachtes Security-Postfach zuerst, dann ein Webformular als Fallback. Jeder gelistete Kanal muss tatsächlich überwacht werden — jeder ist ein implizites Versprechen.
Wovor schützt das Canonical-Feld?
Vor Kopien. Wird deine Datei gespiegelt oder auf eine andere URL gescrapt, benennt Canonical den maßgeblichen Ort — und bei signierten Dateien bindet es die Signatur an genau diese Adresse. Ohne das Feld ist eine veraltete Fremdkopie von deiner echten nicht zu unterscheiden.
Verbessert eine gültige security.txt mein Security-Rating?
Mehrere externe Scanner und Rating-Dienste prüfen darauf, und in Agent-Readiness- und Hygiene-Scores taucht sie ebenfalls auf. Der eigentliche Gewinn ist aber operativ: Sie nimmt jedem Finder die letzte Ausrede, dich nicht zuerst zu kontaktieren.