security.txt für eine Veranstaltungswebsite veröffentlichen
Wer eine Schwachstelle in Veranstaltungsseite, Anmeldung oder Ticketübergabe entdeckt, braucht einen erreichbaren Kontakt. security.txt standardisiert diesen Fundort. Die Datei behebt jedoch keine Schwachstelle und ersetzt keinen Antwortprozess.
Boletolibre-Redaktion
Veröffentlicht
Domain und zuständiges Team festlegen
Bearbeitbare Vorlage herunterladen (Markdown, Englisch)
Listen Sie öffentliche Hostnamen für Veranstaltungsinfos, Anmeldung, Tickets und Kontozugriff samt Betreiber. RFC 9116 begrenzt den Geltungsbereich auf die Domain, unter der die Datei abgerufen wird; Parent und Subdomains sind nicht automatisch umfasst. Beanspruchen Sie keine Zuständigkeit für fremde Checkout-Systeme.[1][2][3]
Einen überwachten Meldeweg wählen
Nutzen Sie ein eigenes Sicherheitspostfach oder sicheres Formular mit Haupt- und Vertretungsperson. Trennen Sie diesen Weg von allgemeinem Gästesupport. Legen Sie Bestätigung, vertrauliche Sichtung und Eskalation fest; bitten Sie nicht um Passwörter, ganze Teilnehmendenexporte oder Kartendaten per Mail.[1][2][3]
Die gültige Mindestdatei veröffentlichen
RFC 9116 verlangt Contact und Expires. Contact ist eine URI wie mailto:security@example.com oder eine HTTPS-Seite, keine bloße Adresse. Für Webdienste liegt die Datei unter https://domain/.well-known/security.txt und wird als text/plain in UTF-8 über HTTPS geliefert. Setzen Sie eine erneuerbare Frist; der RFC empfiehlt weniger als ein Jahr.[1][2][3]
Meldedatei und Offenlegungsregeln unterscheiden
Ein optionales Policy-Feld darf auf eine tatsächlich verabschiedete Richtlinie zeigen. security.txt allein erlaubt keine Tests, schafft keinen rechtlichen Schutz, kein Preisgeld und keine zugesagte Antwortzeit. Lassen Sie solche Zusagen durch Zuständige prüfen und benennen Sie Domains und Anbieter im Geltungsbereich.[1][2][3]
Öffentliche Datei und Eingang prüfen
Rufen Sie die exakte HTTPS-URL ohne Mitarbeiterzugang ab. Kontrollieren Sie Klartext, gültige Contact- und Expires-Werte und die Zielorganisation. Senden Sie eine harmlose interne Testmeldung und stellen Sie sicher, dass Haupt- und Vertretungsperson den Eingang finden. Wiederholen Sie dies nach Domain- oder Hostingwechsel.[1][2][3]
Meldungen getrennt von bestätigten Vorfällen behandeln
Dokumentieren Sie Hostname, Eingangszeit, Kanal, Besitzer, Bestätigung und nächsten Schritt vertraulich. Eine Schwachstellenmeldung ist noch kein nachgewiesener Einbruch. Bei Hinweisen auf aktive Ausnutzung oder offengelegte Gästedaten eskalieren Sie nach Ihrem Vorfallplan.[1][2][3]
Quellen und weiterführende Informationen
- How to Setup security.txt: A Detailed GuideSiteSecurityScore · Abgerufen
- RFC 9116: A File Format to Aid in Security Vulnerability DisclosureIETF RFC Editor · Abgerufen
- Vulnerability Disclosure ToolkitUK National Cyber Security Centre · Abgerufen