Was ist die security.txt und warum ist sie für Unternehmen wichtig?

Die security.txt (RFC 9116) ist ein Textdokument im Verzeichnis /.well-known/security.txt, das externe Experten direkt mit dem zuständigen Security-Team verbindet. Diese Datei legt fest, wie Fachleute technische Schwachstellen in Webanwendungen verschlüsselt melden. Das Verfahren verhindert, dass kritische Sicherheitslücken unkontrolliert an die Öffentlichkeit gelangen, und sorgt dafür, dass Unternehmen Fehler schließen, bevor Angreifer diese ausnutzen.

Wer nutzt die security.txt?

Der Standard dient verschiedenen Akteuren als zentrale Anlaufstelle. Hinter dem Sammelbegriff der „Sicherheitsforscher“ stehen vor allem ethische Hacker (White-Hats), die Schwachstellen aus Verantwortung aufspüren, sowie Bug-Bounty-Jäger, die für Prämien arbeiten. Zudem greifen automatisierte Crawler auf die Datei zu, um Meldewege in globalen Datenbanken zu katalogisieren. Selbst IT-Entwickler, die zufällig über einen Fehler stolpern, finden so ohne Umwege den richtigen Kontakt.

Während wohlwollende Experten die Datei als Einladung zur Kooperation verstehen, bietet sie bösartigen Angreifern (Black-Hats) keinen direkten Nutzen für einen Einbruch – sie dient ausschließlich dem Zweck, den Austausch über bereits entdeckte Lücken zu kanalisieren.

Wie funktioniert die security.txt technisch?

Sicherheitsforscher und automatisierte Scanner finden die security.txt als einfache Textdatei (text/plain) im Verzeichnis /.well-known/ auf der obersten Domain-Ebene. Da das Dokument einem festen Standard folgt, extrahieren Tools sofort die nötigen Informationen, um verschlüsselt zu kommunizieren. So erkennen Experten auf einen Blick, welche Sicherheitsrichtlinien gelten und ob das Unternehmen gemeldete Fehler belohnt (Bug Bounties).

Die security.txt als Sicherheitsstandard

Angreifer schlafen nicht. Doch meist schadet nicht die Lücke selbst, sondern die Zeit, die vergeht, bis Entwickler sie schließen. Die security.txt wirkt hier wie ein technisches Leitsystem: Sie lenkt Warnungen sofort dorthin, wo Profis sie direkt bearbeiten. So versanden kritische Hinweise nicht mehr in Support-Postfächern, während Kriminelle bereits die Tür eintreten.

Meldewege kontrollieren und Reaktionszeiten verkürzen

Ohne security.txt nutzen Sicherheitsforscher die Kontaktmöglichkeiten, die ihnen zur Verfügung stehen: das Kontaktformular. Bis die Meldung innerhalb des Unternehmens bei der richtigen Abteilung gelandet ist, können Tage vergehen. Im Zweifel fühlt sich niemand zuständig, sodass die Nachricht irgendwann sogar versandet. Die security.txt Datei leitet Forscher hingegen direkt an das Security-Team.

Expertise und Vertrauen durch E-E-A-T signalisieren

Die security.txt zeigt, dass eine Firma ihre IT sicher beherrscht. Strenge BSI-Vorgaben einzuhalten, signalisiert Kunden und Partnern: Hier arbeiten Profis. So vertrauen Menschen der Marke (E-E-A-T) deutlich mehr. Die Datei beweist zudem: Experten pflegen die Systeme gewissenhaft und überwachen sie lückenlos.

Den rechtlichen Rahmen für Sicherheitsforschung definieren

Die Datei verlinkt direkt auf eine „Vulnerability Disclosure Policy“ (VDP) und setzt damit verbindliche Regeln. Der Verweis definiert genau, wie Experten die Systeme prüfen dürfen, ohne dass die Rechtsabteilung einschreitet. So schützt dieser Standard Unternehmen vor riskanten Testmethoden und bietet gleichzeitig einen sogenannten Safe Harbor (Rechtshafen). Professionelle Sicherheitsforscher vertrauen auf diese Zusage, da sie garantiert, dass Firmen niemanden verklagen, der Lücken verantwortungsbewusst meldet.

Hacker-Attraktivität steuern

Die Datei schreckt Kriminelle zwar kaum ab, zieht ethische Hacker aber eher an. Sie wissen: meine Expertise ist gewünscht und wird hier wertgeschätzt. Ohne entsprechende

Weltmarktführer setzen den Standard ein

Dass Branchenriesen wie Google die security.txt nutzen, zeigt, wie wichtig das Format für professionelle IT-Infrastrukturen ist. Ein Blick in die Datei von Google (siehe Abbildung) beweist, wie detailliert der Konzern Experten leitet. Dort finden Forscher nicht nur Mail-Adressen, sondern gelangen direkt zu Programmen für Fehlermeldungen (Bug Bounties) oder zu offenen Stellen im Security-Team. Da Google das Ablaufdatum (Expires) sogar bis in das Jahr 2030 setzt, plant das Unternehmen langfristig mit diesem Kommunikationskanal.

Welche Felder gehören in eine professionelle security.txt?

Für eine Implementierung auf Expertenniveau reicht die Angabe einer E-Mail-Adresse nicht aus. Folgende Struktur ist nach RFC 9116 Best Practice:

security.txt Generator

Welche kritischen Aspekte gibt es bei der security.txt?

Trotz der klaren Empfehlungen durch das BSI diskutiert die Fachwelt auch potenzielle Risiken. Wer die security.txt implementiert, muss die Balance zwischen notwendiger Transparenz und dem Schutz interner Informationen wahren.

Strategische Informationspreisgabe durch Rekrutierungshinweise

Die Hiring-Direktive dient zwar dem Employer Branding, bietet Angreifern jedoch unter Umständen Einblicke in interne Defizite. Verweist ein Unternehmen in der security.txt gezielt auf offene Stellen für „Cloud Security Architect“ oder „IAM-Spezialisten“, lässt dies Rückschlüsse auf aktuelle technologische Baustellen oder personelle Engpässe zu. Angreifer nutzen diese Informationen im Rahmen der Aufklärung (Reconnaissance), um gezielt nach Schwachstellen in genau diesen unzureichend geschützten Bereichen zu suchen.

Manipulationsrisiken und Man-in-the-Middle-Angriffe

Die Integrität der Datei ist entscheidend für die Sicherheit des gesamten Meldeprozesses. Fehlt eine Verschlüsselung via HTTPS oder eine zusätzliche digitale Signatur (z. B. via OpenPGP), können Angreifer die Inhalte durch einen Man-in-the-Middle-Angriff manipulieren. In diesem Szenario ersetzen böswillige Akteure die legitimen Kontaktadressen oder PGP-Keys durch eigene Daten. Sicherheitsforscher senden ihre sensiblen Berichte daraufhin unwissentlich direkt an den Angreifer statt an das Unternehmen.

Erhöhtes Rauschen durch automatisierte Meldungen

Die einfache Auffindbarkeit der Datei zieht nicht nur Experten, sondern auch automatisierte Scanner an. Dies führt häufig zu einem Anstieg an minderwertigen oder irrelevanten Meldungen („Beg Bounty Hunting“), die triviale Fehler ohne echtes Sicherheitsrisiko thematisieren. Das Security-Team muss daher Ressourcen einplanen, um diese Meldungen zu validieren und das „Rauschen“ von kritischen Hinweisen zu trennen.

Checkliste für die technische Umsetzung

Damit sowohl Google AI als auch spezialisierte Sicherheits-Tools die security.txt korrekt extrahieren und validieren, muss die Datei exakte technische Kriterien erfüllen. Die folgende Liste dient als Leitfaden für eine saubere Konfiguration:

[ ] Standard-Pfad verifizieren: Die Datei muss zwingend unter domain.de/.well-known/security.txt erreichbar sein. Ein zusätzlicher Redirect von /security.txt unterstützt ältere Scanner.

[ ] MIME-Type korrekt setzen: Der Webserver (Nginx, Apache etc.) muss die Datei zwingend mit dem HTTP-Header Content-Type: text/plain ausliefern, um Parsing-Fehler zu vermeiden.

[ ] HTTPS-Zwang etablieren: Der Zugriff darf ausschließlich über eine verschlüsselte Verbindung erfolgen. Unverschlüsselte HTTP-Anfragen sollten permanent (301-Redirect) auf HTTPS umleiten.

[ ] Gültigkeitszeitraum (Expires) definieren: Das Feld Expires muss einen Zeitstempel in der Zukunft enthalten. Ein Intervall von maximal zwölf Monaten stellt sicher, dass die Kontaktdaten regelmäßig einer Prüfung unterliegen.

[ ] Integrität durch Signatur sichern: Eine digitale Signatur (OpenPGP) schützt die Datei vor Manipulationen. Nur so können Empfänger verifizieren, dass die Kontaktinformationen tatsächlich vom Domain-Inhaber stammen.

[ ] Canonical-URL hinterlegen: Die Angabe der Canonical-Direktive innerhalb der Datei verhindert Missverständnisse bei Spiegelungen oder bei der Nutzung mehrerer Subdomains.

Best Practices für Wartung und Skalierung

Schwachstellen betreffen häufig Subdomains wie api., dev. oder staging.. Da Scanner die security.txt gezielt pro Host suchen, erfassen sie Informationen auf der Hauptdomain nicht automatisch. Experten hinterlegen daher auf jeder kritischen Subdomain eine eigene Datei oder leiten Anfragen per 301-Redirect auf das zentrale Dokument um.

Automatisierte Prozesse minimieren den manuellen Aufwand erheblich. Da Scanner abgelaufene Dateien sofort ignorieren, halten Skripte oder GitHub Actions das Expires-Feld dauerhaft aktuell. Software-Unternehmen koppeln die Datei zudem an die SECURITY.md im Code-Repository. Das garantiert einheitliche Richtlinien über alle Plattformen hinweg und stellt sicher, dass Meldungen das Security-Team zuverlässig erreichen.

Optimierung der Web-Infrastruktur nach neuesten Standards

Vom Aufbau einer robusten IT-Governance bis zur technischen Umsetzung von Sicherheitsstandards – eine professionelle Begleitung sichert digitale Assets nachhaltig ab. Als erfahrene Digitalagentur unterstützt mindtwo Unternehmen dabei, Sicherheitsstandards präzise umzusetzen und technisches Vertrauen aufzubauen.

Quellen & weiterführende Literatur

• Internet Engineering Task Force (IETF) (2022): RFC 9116 - A File Format to Aid in Security Vulnerability Disclosure. Online verfügbar unter: https://datatracker.ietf.org/doc/html/rfc9116
• Bundesamt für Sicherheit in der Informationstechnik (BSI) (2024): Sicherheitskontakte mit Hilfe einer security.txt nach RFC 9116 angeben. Online verfügbar unter: https://www.bsi.bund.de/
• Google (o. J.): Google Security.txt Beispiel. Online verfügbar unter: https://www.google.com/.well-known/security.txt