security-txt.de

BeispieleStand

security.txt Beispiele zum Vergleichen

Vier Dateien für eine fiktive Firma: die kürzeste gültige, eine vollständige nach BSI TR-03183-3, der Aufbau einer signierten Datei und eine mit typischen Fehlern. Ihre eigene Datei mit Ihren Adressen schreibt der Generator.

Minimal nach RFC 9116

Zwei Felder sind Pflicht: Contact und Expires. Mehr braucht eine gültige Datei nicht.

Contact: mailto:security@example.com
Expires: 2027-10-01T00:00:00.000Z

Empfehlenswert sind dazu Preferred-Languages und Canonical. Canonical nennt die Adresse der Datei selbst und macht sie eindeutig, wenn sie kopiert oder signiert wird.

Contact: mailto:security@example.com
Expires: 2027-10-01T00:00:00.000Z
Preferred-Languages: en, de
Canonical: https://www.example.com/.well-known/security.txt

Vollständig nach BSI TR-03183-3

Die TR verlangt die Kontakte in fester Reihenfolge (PSIRT, CSIRT, Meldeseite), je Postfach einen Schlüssel als .asc-Datei, Englisch als Sprache, eine Richtlinie und vor jeder Feldgruppe einen festen Kommentar. Acknowledgments und CSAF sind Soll-Felder.

# Our canonical URI
Canonical: https://www.example.com/.well-known/security.txt

# Our security addresses
Contact: mailto:psirt@example.com
Contact: mailto:csirt@example.com
Contact: https://www.example.com/security-contact

# Our OpenPGP keys
Encryption: https://www.example.com/.well-known/psirt.asc
Encryption: https://www.example.com/.well-known/csirt.asc

# Our preferred languages
Preferred-Languages: en, de

# Our security policy
Policy: https://www.example.com/security-policy

# Our security advisories
CSAF: https://www.example.com/.well-known/csaf/provider-metadata.json

# Our security acknowledgements page
Acknowledgments: https://www.example.com/security-acknowledgments

Expires: 2027-10-01T00:00:00.000Z

Die Kommentare stehen wörtlich so in der TR, auch die britische Schreibweise "acknowledgements" im Kommentar. Das Feld selbst heißt nach RFC 9116 Acknowledgments. Zu dieser Datei gehört nach der TR noch die Signatur.

Aufbau einer signierten Datei

Nach dem Signieren mit gpg --clearsign steht der Inhalt unverändert zwischen einem Kopf und dem Signaturblock. Programme lesen nur den signierten Teil. Der Signaturblock unten ist gekürzt und dient nur zur Anschauung.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

# Our canonical URI
Canonical: https://www.example.com/.well-known/security.txt
...
Expires: 2027-10-01T00:00:00.000Z
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE...
...
-----END PGP SIGNATURE-----

Nach dem Signaturblock darf nichts mehr stehen; solcher Text wäre nicht signiert. Wer die Datei nachträglich ändert, muss neu signieren.

Eine Datei mit typischen Fehlern

So sehen viele Dateien aus, die der Check prüft. Jede Zeile hat ein Problem:

Contact: security@example.com
Contact: http://www.example.com/contact
Encryption: https://www.example.com/pgp-key
Acknowledgements: https://www.example.com/thanks
Canonical: https://example.com/.well-known/security.txt
Expires: 2029-01-01t00:00:00z
Preferred-Languages: Deutsch
ZeileProblem und Korrektur
1E-Mail-Adresse ohne mailto:. Richtig: Contact: mailto:security@example.com
2http statt https; RFC 9116 erlaubt nur https.
3Zeigt auf eine Webseite statt direkt auf die .asc-Datei des Schlüssels.
4Falsch geschrieben, das Feld heißt Acknowledgments. Prüfprogramme übergehen die Zeile.
5Die Datei liegt unter www.example.com, Canonical nennt example.com.
6Mehr als ein Jahr voraus, und t und z klein. Richtig etwa: Expires: 2027-10-01T00:00:00.000Z
7Kein Sprachkürzel. Richtig: Preferred-Languages: de, en

Ob Ihre eigene Datei solche Fehler hat, zeigt der Check in ein paar Sekunden.

Weitere Felder

Drei Felder sind seltener, aber gültig:

Hiring: https://www.example.com/careers
Bug-Bounty: False
CSAF: https://www.example.com/.well-known/csaf/provider-metadata.json

Hiring stammt aus RFC 9116, CSAF und Bug-Bounty aus dem IANA-Register. Bug-Bounty sagt mit True oder False, ob Sie Meldende bezahlen. Alle Felder erklärt die Anleitung.