Was security.txt tatsächlich ist
security.txt ist eine reine Textdatei, definiert in RFC 9116, die jedem, der eine Sicherheitslücke auf deiner Seite findet, genau sagt, wie er sie melden soll. Sie liegt an einem vorhersehbaren Ort — /.well-known/security.txt — sodass Sicherheitsforscher und automatisierte Scanner sich nicht durch deine Kontaktseite wühlen oder eine E-Mail-Adresse raten müssen.
Ein minimales Beispiel sieht so aus:
Contact: mailto:security@example.com
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: de
Das ist das gesamte Format: eine kleine Menge Klartext-Felder, jedes in eigener Zeile. Kein JSON, kein XML, nichts Kompliziertes.
Warum das mehr ist als "nice to have"
Ohne eine security.txt-Datei hat ein Forscher, der eine Schwachstelle auf deiner WordPress-Seite findet, begrenzte Optionen: sich durch dein Kontaktformular wühlen, eine E-Mail-Adresse raten, oder — wenn er nichts Vernünftiges findet — die Schwachstelle öffentlich posten, ohne dir vorher die Chance zu geben, sie zu beheben. Keines dieser Ergebnisse ist gut für dich.
Es gibt auch eine regulatorische Seite. Der EU Cyber Resilience Act, der für Produkte mit digitalen Elementen gilt, die in der EU verkauft werden, verlangt von Herstellern einen dokumentierten Prozess zur Behandlung und Offenlegung von Schwachstellen. security.txt ist nicht die gesamte Compliance-Anforderung, aber der standardmäßige, erwartete Weg, diesen Prozess öffentlich auffindbar zu machen. Wenn deine WordPress-Seite EU-Nutzer bedient oder digitale Produkte verkauft, ist eine eigene Datei ein kleiner, aufwandsarmer Schritt in Richtung dieser breiteren Erwartung.
Welche Felder tatsächlich in die Datei gehören
Das RFC definiert mehrere Felder, von denen nicht alle erforderlich sind. Hier ist, was jedes davon tut:
Contact (erforderlich, mindestens eines): Wie man dich erreicht. Kann eine E-Mail (mailto:), eine URL zu einem Meldeformular, oder beides sein. Du kannst mehrere Contact-Zeilen aufführen, wenn du mehr als einen Meldekanal hast.
Expires (erforderlich): Ein ISO-8601-Zeitstempel. Das zwingt dich, die Datei periodisch zu überprüfen und neu zu bestätigen — eine security.txt mit jahrealten, veralteten Kontaktdaten ist wohl schlimmer als keine zu haben. Setze sie auf etwas Realistisches, etwa ein Jahr im Voraus, und aktualisiere sie, wenn sie abläuft.
Encryption (optional): Ein Link zu einem PGP-Schlüssel, falls du möchtest, dass Forscher Berichte mit sensiblen Details verschlüsseln, bevor sie sie senden.
Acknowledgments (optional): Ein Link zu einer Seite, die Forscher würdigt, die Probleme verantwortungsvoll gemeldet haben — ein kleiner Anreiz, nach dem manche Forscher gezielt suchen, bevor sie entscheiden, ob sie melden oder öffentlich offenlegen.
Preferred-Languages (optional): In welchen Sprachen du Berichte lesen kannst.
Canonical (optional): Die autoritative URL der Datei selbst, nützlich, wenn deine Seite über mehrere Domains erreichbar ist.
Policy (optional): Ein Link zu deiner vollständigen Richtlinie zur Offenlegung von Schwachstellen — dem detaillierten Dokument, das Umfang, erwartete Reaktionszeiten und was Forscher von dir erwarten können, beschreibt.
security.txt zu WordPress hinzufügen
Da die "Einstellungen → Permalinks"-Struktur von WordPress die meisten URLs über PHP abwickelt, braucht es einen von zwei Ansätzen, um eine statische Datei unter /.well-known/security.txt liegen zu lassen:
Option A — Die Datei direkt per FTP/Dateimanager hochladen. Erstelle eine Datei namens security.txt mit dem obigen Inhalt und lade sie in das .well-known-Verzeichnis im Web-Root deiner Seite hoch (erstelle das Verzeichnis, falls es nicht existiert). Das funktioniert praktisch auf jedem Host und hängt überhaupt nicht von WordPress ab, was tatsächlich ein Vorteil ist — es funktioniert weiter, selbst wenn du Themes oder Plugins wechselst.
Option B — Ein Plugin nutzen, das es für dich verwaltet. Eine statische Datei manuell zu pflegen bedeutet, sich daran zu erinnern, das Expires-Feld jährlich zu aktualisieren und die Kontaktdaten synchron zu halten, falls sie sich ändern. Erdo CRA Compliance erzeugt und liefert eine security.txt-Datei als Teil seines breiteren EU-Compliance-Scans, zusammen mit den anderen Dokumenten (Richtlinie zur Offenlegung von Schwachstellen, SBOM), die der Cyber Resilience Act erwartet — sodass alles an einem Ort gepflegt wird, statt als vergessene statische Datei von vor drei Jahren.
Häufige Fehler
Ein paar Dinge, die sich nach dem Hinzufügen der Datei zu prüfen lohnen:
- Vergessen, Expires zu aktualisieren. Eine abgelaufene security.txt signalisiert mehr Vernachlässigung als eine fehlende. Setze eine Kalendererinnerung oder nutze ein Tool, das das für dich verwaltet.
- Eine Kontaktadresse nutzen, die niemand überwacht. Wenn security@deinedomain.de in ein Postfach läuft, das niemand prüft, hast du das Auffindbarkeitsproblem gelöst und eine neue Sackgasse geschaffen.
- Es nur im Domain-Stamm platzieren. /.well-known/security.txt ist der aktuelle Standardort. Ein /security.txt auf Root-Ebene ist als Fallback für ältere Crawler erlaubt, aber verlass dich nicht allein darauf.
- Es als die gesamte Compliance-Geschichte behandeln. security.txt macht deinen Meldekanal auffindbar; es ersetzt nicht, einen echten Triage-Prozess zu haben, wenn eine Meldung eingeht.
Fazit
security.txt ist eine Fünf-Minuten-Lösung mit überproportionalem Nutzen: Sie verwandelt "Ich habe einen Fehler auf deiner Seite gefunden, was jetzt?" von einer Sackgasse in einen dokumentierten Prozess. Egal ob du sie manuell als statische Datei hinzufügst oder ein Compliance-Tool sie zusammen mit deinen anderen EU-Dokumenten pflegen lässt — es ist eine der aufwandsärmsten, wirkungsvollsten Sicherheitspraktiken, die eine WordPress-Seite übernehmen kann.