Adding a security.txt to your website

If someone finds a security vulnerability in your website, such as an open directory or an outdated plugin, you want that person to be able to warn you. That's what security.txt is for: a small text file in a fixed location on your website, containing the address where such reports should go. It's defined in the internet standard RFC 9116. Here you can read what goes in it and how to set it up.

The location

The file lives at https://example.com/.well-known/security.txt. The old location /security.txt in the root directory is allowed as an extra, but if the file exists in both places, the one in /.well-known/ takes precedence. It must be reachable over https and served as plain text (text/plain).

The file only applies to the name it's hosted on. So a security.txt on example.com doesn't automatically apply to shop.example.com. If a subdomain has its own website, put a security.txt there too.

What goes in it

Contact: mailto:security@example.com
Expires: 2027-10-31T23:00:00Z
Preferred-Languages: nl, en
Canonical: https://example.com/.well-known/security.txt

Field	Required?	Meaning
`Contact`	Yes	Where reports should go: a `mailto:` address, a `tel:` number or a web page starting with `https://`. You can list several below each other; the first one is your preference.
`Expires`	Yes, exactly once	The date and time after which the file is considered outdated, such as `2027-10-31T23:00:00Z`. The standard recommends a date less than a year ahead.
`Preferred-Languages`	No	The languages in which you want to receive reports.
`Canonical`	No	The address of the file itself.
`Policy`	No	A link to a page with your reporting policy: what you do with a report and what you ask of the reporter.
`Encryption`	No	A link to your public key, if reporters may send you encrypted email.

For Contact, use an address that someone actually reads. A forgotten mailbox is worse than no security.txt at all: the reporter thinks you've been warned. Signing with a digital signature (OpenPGP) is allowed, but not required.

Setting it up on your hosting package

In DirectAdmin, open File Manager and go to domains/example.com/public_html. See Opening File Manager: the folders in your package.
If the .well-known folder doesn't exist yet, create it. Folders starting with a dot only show up once you display hidden files: see Showing and editing hidden files such as .htaccess.
Create a new file security.txt in that folder, paste your lines into it and save.
Open https://example.com/.well-known/security.txt in your browser. You should see your text.

If you use WordPress or another CMS, nothing changes: a file that actually exists is simply served by the web server.

Setting it up on a VPS

On a VPS, you place the file in your site's web directory, for example /var/www/example.com/.well-known/security.txt. Pay attention to two things:

If you block all paths starting with a dot in nginx, first add an exception for /.well-known/.
If an application runs behind a reverse proxy, make the path point to the file in Caddy or nginx.

See Caddy: a website with automatic https and nginx with a certificate from Let's Encrypt.

Checking

View the headers with:

curl -sI https://example.com/.well-known/security.txt

The status should be 200 and the type text/plain. A common mistake: a site that answers every unknown address with the homepage. The file then appears to exist, but HTML comes back. So check the content as well. The website test at internet.nl also checks security.txt.

Update it every year

Set a reminder in your calendar well before the date in Expires. Then check whether the contact address is still correct and move the date forward. If something changes in between, such as a new address or someone leaving, update the file right away.

Cookies at WebOké

Cookie settings

Necessary

Marketing