security-txt.eu

ExamplesAs of

security.txt examples to compare against

Four files for a fictitious company: the shortest valid one, a complete one under BSI TR-03183-3, the structure of a signed file and one with typical mistakes. The generator writes your own file with your addresses.

Minimal under RFC 9116

Two fields are required: Contact and Expires. A valid file needs nothing more.

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

Preferred-Languages and Canonical are worth adding. Canonical names the address of the file itself and makes it unambiguous when it is copied or signed.

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

Complete under BSI TR-03183-3

The TR requires the contacts in a fixed order (PSIRT, CSIRT, reporting page), one key per mailbox as an .asc file, English as a language, a policy and a fixed comment before each group of fields. Acknowledgments and CSAF are recommended fields.

# 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

The comments are worded exactly as in the TR, including the British spelling "acknowledgements" in the comment. The field itself is called Acknowledgments under RFC 9116. Under the TR this file still needs its signature.

Structure of a signed file

After signing with gpg --clearsign, the content stays unchanged between a header and the signature block. Parsers read only the signed part. The signature block below is shortened and for illustration only.

-----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-----

Nothing may follow the signature block; such text would not be signed. If you change the file afterwards, sign it again.

A file with typical mistakes

Many files the checker sees look like this. Every line has a 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
LineProblem and fix
1E-mail address without mailto:. Correct: Contact: mailto:security@example.com
2http instead of https; RFC 9116 allows only https.
3Points to a web page instead of directly to the key's .asc file.
4Misspelt, the field is Acknowledgments. Parsers ignore the line.
5The file lives at www.example.com, Canonical names example.com.
6More than a year ahead, and lower-case t and z. Correct, for example: Expires: 2027-10-01T00:00:00.000Z
7Not a language tag. Correct: Preferred-Languages: de, en

The checker shows within seconds whether your own file has such mistakes.

More fields

Three fields are less common but valid:

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

Hiring comes from RFC 9116, CSAF and Bug-Bounty from the IANA registry. Bug-Bounty states with True or False whether you pay reporters. All fields are explained in the guide.