Zum Inhalt springen
OM-IT Systeme – Startseite

security.txt prüfen und erstellen

Prüfen Sie, ob Ihre Domain eine gültige security.txt nach RFC 9116 hat – wichtig für verantwortungsvolle Sicherheitsforscher und Ihr Unternehmen.

Keine SpeicherungRFC 9116 konformRFC 9116

So funktioniert die Prüfung

Wir prüfen, ob Ihre Website eine gültige security.txt hat: eine Kontaktangabe, über die Sicherheitsforscher gefundene Lücken melden können (Standard RFC 9116).

  • Domain eingeben: Nur die Domain (z. B. firma.de), ohne https:// oder www.
  • Automatische Prüfung: Wir suchen unter /.well-known/security.txt und /security.txt.
  • Prüfung nach Standard: Pflichtfelder wie Kontakt (Contact) und Ablaufdatum (Expires) sowie weitere Angaben nach RFC 9116.

Was ist security.txt?

Die security.txt ist ein Standard (RFC 9116), der Sicherheitsforschern zeigt, wie sie Schwachstellen verantwortungsvoll melden können. Große Unternehmen wie Google, Microsoft und Meta nutzen sie bereits.

RFC 9116 – Der offizielle Standard

Security.txt prüfen

Nur die Domain, z. B. firma.de – ohne https:// und ohne Pfad.

security.txt erstellen

Die Datei entsteht direkt in Ihrem Browser. Ihre Angaben werden nicht gesendet und nicht gespeichert.

E-Mail-Adresse, Telefonnummer mit +49 oder https-Adresse eines Kontaktformulars.

Vorschau

Geben Sie Domain und Kontakt ein, dann erscheint hier die fertige Datei.

Legen Sie die Datei unter /.well-known/security.txt auf Ihrem Webserver ab und prüfen Sie sie danach oben mit dem Check.

Die Felder der security.txt nach RFC 9116

FeldPflicht?Bedeutung
ContactPflicht, mindestens einmalWie Sicherheitsforscher eine Lücke melden: E-Mail als mailto:, Telefon als tel:, Webseiten nur mit https://.
ExpiresPflicht, genau einmalAb wann die Angaben als veraltet gelten. Empfohlen: weniger als ein Jahr in der Zukunft.
EncryptionoptionalWo Ihr öffentlicher Schlüssel liegt, damit Meldungen verschlüsselt ankommen.
PolicyoptionalLink auf Ihre Richtlinie: was gemeldet werden darf und wie Sie damit umgehen.
AcknowledgmentsoptionalSeite, auf der Sie Meldenden danken.
Preferred-Languagesoptional, höchstens einmalSprachen für Meldungen, z. B. de, en. Fehlt das Feld, gehen Forscher von Englisch aus.
CanonicaloptionalDie Adresse(n), unter denen die Datei gültig ist. Empfohlen, wenn Sie die Datei signieren.
HiringoptionalLink auf offene Stellen im Bereich IT-Sicherheit.

Zusätzlich empfiehlt der Standard, die Datei mit einer OpenPGP-Klartextsignatur zu signieren. Beispiel einer minimalen gültigen Datei:

Contact: mailto:security@firma.de
Expires: 2027-10-10T23:59:00.000Z
Preferred-Languages: de, en
Canonical: https://firma.de/.well-known/security.txt

Häufige Fehler

  • Expires fehlt oder liegt in der Vergangenheit – dann gilt die ganze Datei als veraltet.
  • Die Datei liegt nur unter /security.txt. Maßgeblich ist /.well-known/security.txt; der alte Ort ist nur für Altsysteme gedacht.
  • Die Datei kommt als HTML-Seite zurück, etwa weil das CMS eine Fehlerseite mit Status 200 liefert. Verlangt ist text/plain mit utf-8 über HTTPS.
  • Der Kontakt steht ohne Schema in der Datei (security@firma.de statt mailto:security@firma.de).
  • Expires oder Preferred-Languages stehen mehrfach in der Datei.
  • Canonical zeigt auf eine andere Domain als die, unter der die Datei liegt.

Häufige Fragen zur security.txt

Das Werkzeug steht frei zur Verfügung, auch ohne Kunde zu sein. Betreuen Sie die IT eines Unternehmens im Oldenburger Münsterland? Wir richten security.txt und Disclosure-Prozesse ein – als Einzelmaßnahme oder als Teil der laufenden Betreuung aus Lohne.

Erstgespräch anfragen Cybersecurity-Leistungen ansehen