Contact for security issues (security.txt)

What we check

We request https://example.ch/.well-known/security.txt, alternatively /security.txt. The file is standardised in RFC 9116 and says how to report a vulnerability to the operator of the website.

• Present? If it is missing, we give a note. If the server answers with a normal HTML page instead of the file, it counts as missing too.
• Contact: the contact entry is mandatory. Without it the file is useless. It should be an address with a scheme, that is mailto:, https:// or tel:.
• Expires: the expiry date is mandatory. If it is missing, unreadable or in the past, we warn.
• Place and transport: if the file only lies in the old place /security.txt or is only delivered over HTTP, we give a note.

In the report you see the contacts and the expiry date.

Why it matters

Vulnerabilities are often discovered by outsiders: by researchers who check websites systematically, by the professionals of a customer or by someone who happens to notice something. These people usually want to warn the operator. If they find no contact, they write to an address nobody reads, or they let it be. The vulnerability stays open.

The security.txt solves this with a small text file in a fixed place. Tools and researchers look there first. Authorities such as the US CISA, the UK NCSC or the German BSI and many companies use it, and public tenders increasingly require it.

The expiry date makes sure the details are maintained. An expired file signals the opposite of what it is meant to.

How to fix it

Put a text file with this content at /.well-known/security.txt:

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

• Contact: at least one address that is read reliably. Several lines are allowed, the most important first.
• Expires: date and time in the format shown, at most one year ahead. Set yourself a reminder to extend it.
• Preferred-Languages: the languages in which reports are accepted.
• Canonical: the full address of the file, so that copies in other places can be recognised.

The .well-known folder lies in the root directory of the website. On securitytxt.org there is a generator that creates the file.

WordPress

Put the file in the .well-known folder via FTP or the file manager of the hosting provider. Alternatively there are plugins such as "Security.txt" that deliver the file from the settings.

Wix, Jimdo, Squarespace

The builders usually allow no custom files in this place. Check whether the provider has a setting for it, or fall back to a "Security" page with the contact address.

How to check it yourself

Open https://example.ch/.well-known/security.txt in the browser. You should see the plain text of the file, no error page and no normal page of the website.

Frequently asked questions

Does a security.txt not invite attackers in the first place?

No. Anyone who wants to attack needs no invitation. The file reaches the others: researchers and professionals who find a vulnerability by chance and want to report it instead of ignoring it.

How much does the security.txt count in the score?

Little, at most 2 of 100 points in the security area. It is a sign of careful handling of security that many smaller websites do not show yet.

Which email address belongs in it?

One that is read reliably, for example the general company address or that of the IT support. A dedicated address such as security@ is common, but not a must.