A Self-Hosting Essential: Does Your Public Service Have a security.txt?

What Is security.txt

In the self-hosting community on Reddit, a seemingly niche but genuinely important question was raised for anyone running public-facing services: Do you provide a security.txt file for your publicly accessible services?

security.txt is a proposed internet standard (RFC 9116) designed to give websites and online services a unified channel through which security researchers can quickly find the organization's security contact information. The core idea is straightforward: when a well-intentioned white-hat researcher discovers a vulnerability in your service, they should have a clear, standardized place to look for instructions on how to responsibly disclose the issue.

How It Works

security.txt is essentially a plain-text file that, by convention, should be placed at /.well-known/security.txt on your website (earlier versions also allowed it in the root directory). When a security researcher wants to contact you, this is the first place they'll look.

The file uses a simple key-value format. Common fields include:

• Contact: Required. Can be an email address, phone number, or URL for a contact page — used for vulnerability reports.
• Expires: The file's expiration date, reminding maintainers to update it regularly.
• Encryption: A link to a public encryption key, enabling secure transmission of sensitive information.
• Acknowledgments: A credits page listing researchers who have previously reported vulnerabilities.
• Policy: A link to your security policy or vulnerability disclosure policy.
• Preferred-Languages: Your preferred language(s) for communication.

A minimal example might be just one line — Contact: mailto:[email protected] — plus an Expires field. The setup cost is extremely low.

security.txt files are also commonly recommended to be digitally signed with OpenPGP to prevent attackers from tampering with the file and replacing your security contact information with malicious addresses. A signed file includes a PGP signature block at the end, which researchers can verify against the maintainer's publicly available public key. The /.well-known/ path convention comes from RFC 8615 — it's the designated directory in internet standards for storing "well-known metadata." Beyond security.txt, files like ACME certificate validation challenges and Apple App Site Association files follow the same convention, which is why most security scanning tools prioritize checking this path.

Why Self-Hosting Users Should Care

Many people assume security.txt is only relevant for large enterprises, but it has real value for individual self-hosters as well. Once you expose services like Nextcloud, Jellyfin, a personal blog, or various dashboards to the public internet, you've already become a potential target — and a potential discovery for well-meaning researchers.

Without a clear contact channel, anyone who discovers a misconfiguration or vulnerability in your service often has no way to notify you, or simply gives up trying. Providing a security.txt is like leaving a "responsible disclosure" door open — turning a potential exploit into a friendly heads-up.

From a maintenance standpoint, adding a static file like this is virtually zero overhead. It requires no additional services, consumes no compute resources, and is just one more text response your web server returns.

Responsible Disclosure (also called Coordinated Disclosure) is an established norm in the security community. The core principle is that after discovering a vulnerability, researchers privately notify the affected party first and allow a reasonable window for remediation — typically 90 days — before choosing to publish publicly. This model benefits both sides: researchers receive recognition or rewards, while operators get a chance to patch the issue before it's exploited. Conversely, if an operator has no reachable contact channel, researchers may either give up entirely or go straight to full public disclosure — which poses far greater risk to the service's security. Bridging this communication gap is the core value proposition of security.txt.

Real-World Adoption

One reality highlighted in the discussion is that despite security.txt being an RFC standard, adoption rates in the personal self-hosting community remain low. Most self-hosting users are focused on functionality and access security — reverse proxies, HTTPS, two-factor authentication — and rarely think about the passive scenario of being contacted from the outside.

This reflects a common mindset: personal services are small-scale with limited blast radius, so investing in a security disclosure channel seems unnecessary. But that "it doesn't matter" attitude is precisely what leaves many small services without a timely response mechanism when something goes wrong.

Practical Recommendations

If you decide to add security.txt to your public-facing services, here are some key points to keep in mind:

1. Put it in the right place: Use /.well-known/security.txt and make sure it's accessible over HTTPS.
2. At minimum, fill in Contact and Expires: These are the baseline requirements of the standard.
3. Set a reasonable expiration date: No more than one year is recommended — and make it a habit to update before it expires.
4. Consider your privacy: If you'd rather not expose a personal email, use a dedicated security contact alias.
5. Pair it with a security policy: Even a brief statement saying you welcome responsible disclosure can significantly improve communication efficiency.

For users running Caddy, Nginx, or similar servers, serving this file typically requires just a few lines of configuration.

Wrapping Up

security.txt is a low-cost, high-value practice. It won't make your service more secure on its own, but it smooths the path from "vulnerability discovered" to "vulnerability resolved." For anyone hosting public-facing services — whether a business or an individual self-hoster — spending a few minutes to deploy this file is absolutely worth the effort.