security.txt in 5 Minuten einrichten — ein Einstieg in die Offenlegung von Sicherheitslücken | Scanthra

Scanthra · 6 Min Lesezeit · Aktualisiert Mai 2026

Was security.txt eigentlich ist

security.txt ist eine kleine, maschinenlesbare Klartextdatei, die du auf deiner Website veröffentlichst. Es ist das Sicherheitsäquivalent von robots.txt: ein bekannter Speicherort, eine einfache Syntax und ein klarer Zweck. Die Datei beantwortet eine Frage für jemanden, der glaubt, eine Sicherheitslücke auf deiner Website gefunden zu haben — „Wem sage ich das, und wie?"

Das Format ist standardisiert in IETF RFC 9116 („A File Format to Aid in Security Vulnerability Disclosure"). Es wurde 2022 zum Proposed Standard erklärt — kein Entwurf und keine Besonderheit mehr, sondern der vereinbarte Weg, das zu tun.

Warum das auch gilt, wenn du keine Bank bist

Drei Gründe, die fünf Minuten wert sind:

• Forscher können dich erreichen. Ohne einen klaren Kanal geben gut gemeinte Finder entweder auf, veröffentlichen das Problem öffentlich oder schicken es an dein generisches Kontaktformular. Eine dokumentierte Adresse fängt das Problem früh und privat ab.
• Einkauf und Fragebögen erwarten es. Lieferantensicherheitsfragebögen (SIG, CAIQ, unternehmenseigene) und NIS2 (EU-Cybersicherheits-Richtlinie)-ähnliche Checklisten fragen zunehmend: „Veröffentlichst du eine Vulnerability-Disclosure-Policy?" Eine aktive security.txt ist die günstigste mögliche Antwort „Ja".
• Sie signalisiert Reife. Eine Website mit einer aktuellen security.txt zeigt, dass der Inhaber über den Ernstfall nachgedacht hat. Das allein hebt dich aus dem untersten Viertel heraus.

Die Felder, die RFC 9116 definiert

Nur Contact und Expires sind Pflicht. Der Rest ist optional, aber nützlich.

• Contact: — Pflicht. Eine oder mehrere Kontaktmöglichkeiten: eine E-Mail (mit mailto: vorangestellt), eine Telefonnummer (tel:) oder eine Meldeseite (https://). Mehrere Contact-Zeilen sind erlaubt; liste sie in der Reihenfolge deiner Präferenz auf.
• Expires: — Pflicht. Ein ISO-8601-Zeitstempel, nach dem diese Datei nicht mehr als vertrauenswürdig gelten soll. Die meisten Teams setzen ihn 6–12 Monate in die Zukunft und erneuern ihn per Kalender-Erinnerung.
• Encryption: — eine URL zu deinem PGP-öffentlichen Schlüssel, wenn du verschlüsselte Berichte möchtest. Optional, aber willkommen.
• Acknowledgments: — eine URL zu einer Seite, auf der du Forschern dankst, die Probleme verantwortungsvoll gemeldet haben. Kostenlose gute Geste.
• Preferred-Languages: — kommagetrennte BCP-47-Sprach-Tags (z. B. de, en). Du kannst sie weglassen — die meisten Teams verstehen Englisch plus ihre eigene Sprache sowieso.
• Canonical: — die kanonische URL dieser Datei. Nützlich, wenn deine Website unter mehreren Hostnamen erreichbar ist; sagt Parsern, welche Kopie maßgeblich ist.
• Policy: — eine URL zu deiner vollständigen Vulnerability-Disclosure-Policy: Umfang, Safe-Harbour-Klausel, erwartete Reaktionszeit.
• Hiring: — eine URL zu deiner Security-Team-Stellenseite. Ja, das ist im Standard drin.
• CSAF: — eine URL zu einer CSAF 2.0-Provider-Metadatendatei. Nur relevant, wenn du maschinenlesbare Advisories veröffentlichst; Kleinunternehmen können das ignorieren.

Ein kopierfertig nutzbares Beispiel

Ersetze E-Mail, Daten und URLs durch deine eigenen. Halte die Datei in reinem ASCII (kein BOM) und verwende UNIX-Zeilenenden. Zeilen, die mit # beginnen, sind Kommentare.

# security.txt for example.com
# Please report security issues using the contacts below.

Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2027-05-01T00:00:00.000Z
Encryption: https://example.com/.well-known/pgp-key.txt
Acknowledgments: https://example.com/security/hall-of-fame
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security/policy

Wo die Datei hingehört

Der kanonische Speicherort ist:

https://deinedomain.de/.well-known/security.txt

Der ältere Speicherort /security.txt im Dokumentenroot wird von den meisten Tools ebenfalls akzeptiert, aber der /.well-known/-Pfad ist der vom RFC 9116 vorgeschriebene — verwende diesen.

nginx

location = /.well-known/security.txt {
    alias /var/www/example.com/.well-known/security.txt;
    default_type text/plain;
    add_header Cache-Control "public, max-age=3600";
}

Apache

<Files "security.txt">
    ForceType text/plain
    Header set Cache-Control "public, max-age=3600"
</Files>

Lege die Datei einfach unter /var/www/example.com/.well-known/security.txt ab und stelle sicher, dass Apache versteckte Verzeichnisse ausliefern darf (einige Standardkonfigurationen blockieren Pfade mit .-Prefix).

Statische Hosts, WordPress, Cloudflare Pages, Vercel, Netlify

Lege eine Datei namens security.txt in einen Ordner namens .well-known in deinem öffentlichen Assets-Verzeichnis und deploye erneut. Die meisten statischen Hosts liefern Dotfile-Verzeichnisse problemlos aus — prüfe es direkt nach dem Deployment durch Aufrufen der URL.

Signieren (optional, aber ordentlich)

RFC 9116 erlaubt, die Datei als clearsigned PGP-Nachricht zu gestalten. Die meisten Kleinunternehmen verzichten darauf — und das ist in Ordnung. Wenn du bereits einen PGP-Schlüssel veröffentlichst, macht das Signieren es schwieriger, die Datei über einen kompromittierten Host zu fälschen. Wenn nicht, überspringe es; eine unsignierte Datei ist vollkommen gültig.

Häufige Fehler, die es zu vermeiden gilt

• Fehlendes Expires-Feld. Eine abgelaufene oder fehlende Expires-Zeile macht die Datei laut Spezifikation ungültig. Parser werden warnen oder die Datei ablehnen.
• Falscher MIME-Typ. Die Datei muss als text/plain ausgeliefert werden; manchmal gibt ein Webserver application/octet-stream zurück und bricht das Parsing.
• Nur HTTPS. security.txt muss über HTTPS an ihrer kanonischen URL ausgeliefert werden. Eine reine HTTP-Version wird ignoriert.
• Privates Postfach bei Contact. Nutze eine Rollen-Adresse wie security@, die Personalwechsel übersteht — nicht jana@.
• Vergessene Erneuerung. Trage das Expires-Datum in denselben Kalender ein, in dem du TLS-Zertifikate erneuert. Eine abgelaufene security.txt ist schlimmer als keine — sie sagt Forschern, dass das Team schläft.

So erkennt Scanthra das Problem

Unser M10-robots-and-well-known-Probe prüft, ob /.well-known/security.txt existiert und über die kanonische HTTPS-URL erreichbar ist. Fehlt die Datei, melden wir eine niedrigschwellige Beobachtung statt eines Befunds — es ist ein „schön zu haben, keine Wunde" — und empfehlen diesen Leitfaden als Lösung. Websites, die bereits eine gültige Datei veröffentlichen, erhalten ein stilles Häkchen in der Compliance-Übersicht.