security.txt Setup:Publish and Verify a Working Report Channel

A security researcher finds a problem on your website. The next step should be obvious: where should the report go, and will anyone read it? A security.txt file makes that contact route discoverable without requiring the researcher to guess an employee's email address.

The useful result is a current file and a monitored reporting channel. A file that returns HTTP 200 but points at an abandoned inbox has not solved the problem.

This guide follows RFC 9116. Examples are templates, not a claim that these settings have been deployed or tested on your site. Documentation reviewed on 16 October 2026.

Choose a reporting route before publishing

Ask who will receive a vulnerability report, who can assess it and who takes over during absence. Use a role mailbox or an existing secure reporting form with an owner. Publishing a new address does not create the mailbox or make it deliverable.

Decide how you will handle sensitive details. If you publish an encryption-key link, maintain the key and the receiving team's ability to use it. Do not invent an OpenPGP URL just to fill an optional field.

Keep vulnerability reporting separate from a general abuse complaint or a claim that the website has been compromised. A contact file helps route information; it is not a scanning service, security certificate or complete incident-response plan.

Create the smallest useful file

Use a plain-text editor and save this as security.txt, replacing the example address and date:

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

The example expiry is deliberately dated. Choose a real future deadline and arrange review before it arrives. Do not leave this example unchanged indefinitely.

For a site with a real disclosure-policy page, an expanded template could be:

Contact: mailto:security@example.com
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policy/
Preferred-Languages: en
Expires: 2027-04-01T00:00:00Z

Remove optional lines you cannot support. A published policy should describe the intended scope and reporting process. Do not promise rewards, response deadlines or authorisation to test systems unless the organisation has agreed to them.

RFC 9116 also recommends signing the file. If you implement signatures, verify the complete signing and key-maintenance process; adding a signature-looking block is not a substitute.

Put it in the correct document root

For a web service, the standard location is:

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

In cPanel, open Domains to identify the correct domain's document root, then use File Manager. Enable display of hidden files if necessary, create .well-known if it does not exist, and upload the file inside it. See cPanel's File Manager documentation.

Do not assume every domain uses public_html. Addon domains and subdomains can use different directories. An upload to the wrong document root can look successful in File Manager while the public URL remains unchanged.

For a deployed application without a writable persistent web root, add the file through the application's supported static-file or route mechanism. A manual file added to an ephemeral deployment may disappear on the next release.

The file's scope does not automatically extend to every subdomain. Inventory the relevant public hostnames and decide where separate files or controlled redirects are appropriate. A legacy /security.txt location is not a replacement for the well-known location.

Verify the public response and the body

Run a GET that saves the headers and body separately:

curl --fail --show-error --silent \
  --connect-timeout 10 --max-time 20 \
  --dump-header security-headers.txt \
  --output security-body.txt \
  https://example.com/.well-known/security.txt

Inspect both files. A successful HTTP response alone can be a custom error page, a login screen or your WordPress homepage. Confirm that the downloaded body contains the intended fields and current values.

Check that the response is served over valid HTTPS as plain text with UTF-8 encoding, that the contact URI is correct, and that there is exactly one Expires field. RFC 9116 recommends an expiry less than a year ahead. Review any redirect before treating the destination as trusted.

For a quick header inspection, use:

curl -I --connect-timeout 10 --max-time 20 \
  https://example.com/.well-known/security.txt

This checks headers for a HEAD request; it does not validate the file contents. It is a supporting check, not the whole verification.

Fix the actual failure

404: confirm the domain's document root, directory spelling and deployment inclusion. Inspect whether the application router consumes the URL.

HTML with HTTP 200: a rewrite or application fallback may be serving the homepage. Test the body after adjusting the exact static route; do not accept the status code as proof.

403: inspect the rule that blocks hidden paths. An administrator can allow this exact public file while retaining restrictions on unrelated hidden files. Avoid a blanket exception for every dot-directory.

Wrong content type: change the response metadata through the web server or application that serves this route. On a panel-managed server, use supported configuration controls. If editing server configuration, back up the effective file, validate syntax and reload through the normal procedure.

Old content after deployment: check the deployed file and relevant CDN cache, then retrieve it again from the public hostname. Purge the affected resource when needed; a full-site purge is not automatically necessary.

For TLS or routing problems, our HTTPS guide and Cloudflare origin-certificate troubleshooting address different parts of the path.

Make maintenance part of the setup

Record the owner, reporting URL, expiry and review date. Recheck after a domain migration, mailbox change, staff handover or application redeployment. Retrieve the file from the public URL rather than checking only a local copy.

Separately confirm that the receiving channel works through an authorised internal test. Monitor the channel and handle real reports according to the published policy.

A reliable reporting route is the outcome. The file is the signpost to it.