What security.txt does

How it works

Whoever discovers a hole in your website usually wants to report it, but often finds only a contact form or a general address. The report then gets lost or ends up in public. security.txt, described in RFC 9116, solves this with a fixed place: https://your-domain/.well-known/security.txt. Security researchers and their tools look there first.

The file consists of lines of the form Field: value. Two fields are required:

• Contact says where reports go: mailto:, the https:// address of a form, or tel:. There may be several; the first is the preferred one.
• Expires says until when the details hold, as a date per RFC 3339, such as 2027-06-30T00:00:00Z.

Optional fields include Preferred-Languages, Canonical (the address of the file itself), Policy (your rules for reports) and Encryption (a key for encrypted reports).

What matters

• The right place. /.well-known/security.txt, over HTTPS. An older file at /security.txt is still found; better redirect it to the intended place.
• A real text file. Served as text/plain. Many websites answer unknown paths with an HTML page; that doesn't count.
• A contact that gets read. Without Contact the file helps nobody, and a mailbox nobody reads hardly more.
• Expires less than a year ahead. RFC 9116 recommends this so stale details expire by themselves. Once the date has passed, check the contacts and set a new one.

How to set it up

A file that will do to start with:

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

Replace domain and address and choose a date less than a year ahead. Upload the file by FTP or your hosting provider's file manager to the .well-known directory of your website, or have your agency do it. Some CMSs have a plugin for it. Put renewing Expires in your calendar.