security.txt for a Personal Website — Give Security Reports a Clear Front Door

A personal website may be small, but it still has doors, windows, and occasionally a loose hinge. If a researcher notices a security problem, the difference between a helpful report and silent frustration can be as simple as publishing one small text file.

That file is security.txt. It does not secure a server by itself, and it is not a replacement for patching, monitoring, or careful configuration. Its job is narrower: tell well-intentioned people how to contact you, what they can expect, and where the boundaries are.

What security.txt Actually Does

security.txt is a standardized contact document described by RFC 9116. Security researchers and automated tools look for it at /.well-known/security.txt. Think of it as the emergency-contact card pinned near the entrance of a building. The card does not install better locks, but it prevents someone who spots smoke from wandering through every hallway looking for the owner.

Without a published route, a reporter may try an old social account, guess an email address, submit a public comment, or give up. A clear file reduces that uncertainty. It also lets you state preferences such as whether reports should be encrypted, which languages you understand, and where your disclosure policy lives.

The Smallest Useful File

A practical file can begin with only two required ideas: a working contact and an expiry date. The contact may be an email address or an HTTPS form. The expiry tells tools and researchers that the instructions are still maintained rather than abandoned years ago.

Contact: mailto:[email protected]
Expires: 2027-08-14T00:00:00Z
Preferred-Languages: en, id, de
Canonical: https://example.com/.well-known/security.txt

Replace the example domain and inbox with addresses you actually monitor. Use an expiry comfortably in the future, but not so far away that you forget the file exists. Six to twelve months is a sensible maintenance rhythm. Add its renewal to the same calendar that reminds you about domains, certificates, and backups.

Useful Fields Without Unnecessary Promises

The Contact field can appear more than once, allowing both email and a web form. Encryption points to a public key if you can receive sensitive reports securely. Acknowledgments links to a page thanking people who helped, while Policy links to rules for responsible testing. Hiring exists too, although most personal sites do not need it.

Only publish fields you can support. An unmonitored “security” inbox is worse than a familiar address you read every day. Likewise, do not promise a 24-hour response or a cash bounty unless you can consistently provide it. A modest statement such as “I aim to acknowledge reports within seven days” is more trustworthy than an impressive service-level target that exists only on paper.

Write a Human Disclosure Policy

The text file is a signpost; a policy page supplies the context. Explain what systems are in scope, what testing is not allowed, what information a useful report should contain, and how you will communicate. For a personal website, scope might include the main domain and its first-party subdomains while excluding third-party services.

Ask researchers to avoid privacy violations, data destruction, denial-of-service testing, social engineering, and accessing more data than needed to demonstrate an issue. Invite them to include the affected URL, reproduction steps, observed impact, and a safe proof of concept. This is similar to leaving repair instructions beside a bicycle: the clearer the expected tools and limits, the lower the chance that help creates a second problem.

Publish It in the Correct Location

The standard location is fixed: https://example.com/.well-known/security.txt. A legacy copy may also exist at /security.txt, but the /.well-known/ route is the authoritative place. Serve it over HTTPS with a text-oriented content type and do not hide it behind authentication, a cookie banner, or a JavaScript-only application.

For a static site, create the directory and commit the file with the rest of the public assets. On Nginx, a direct location can make the response explicit:

location = /.well-known/security.txt {
    default_type text/plain;
    try_files /.well-known/security.txt =404;
}

If a framework intercepts every request, add an exception for this path or place the file in its public directory. Avoid a redirect chain across unrelated domains. The Canonical value should match the final HTTPS location from which the file is served.

Signing Is Optional, Accuracy Is Not

RFC 9116 supports digitally signed content. A signature can help demonstrate that instructions are authentic, especially for larger organizations with established PGP workflows. For a small personal site, an unsigned file delivered through correctly configured HTTPS is often a reasonable starting point.

Do not let signing complexity delay a useful contact route. A pristine signature around an expired date or dead inbox does not help anyone. Operational accuracy matters more: keep the recipient active, protect the inbox with strong authentication, restrict who can access reports, and treat attachments or proof-of-concept code as untrusted input.

Test the Public Result

After publishing, test what an outsider receives rather than trusting the local file. The following commands reveal status, headers, redirects, and body content:

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

Expect a successful response, readable plain text, and the exact current instructions. Check from outside your home network if the site is self-hosted. Then test the contact method itself. Send a harmless message and verify that spam filtering, aliases, and forwarding rules deliver it. A route is only real when a message reaches a person.

Plan for the Report Before It Arrives

Publishing contact details creates a responsibility to respond calmly. Prepare a lightweight process: acknowledge receipt, preserve the original report, reproduce the issue safely, estimate severity, fix and verify the change, then agree on disclosure timing. Not every surprising behavior is a vulnerability, but every respectful report deserves a respectful answer.

Avoid asking the reporter to send secrets they do not need to share. If the issue involves personal data, minimize copies and move the conversation to an encrypted channel when available. Keep brief notes so you can learn whether the root cause was missing updates, unsafe defaults, exposed credentials, or a design assumption that no longer holds.

A Tiny File That Improves the Whole Conversation

security.txt is not glamorous infrastructure. It is closer to labeling the circuit breaker box: a small act of maintenance that becomes valuable exactly when something goes wrong. It helps a researcher reach the right person, helps you receive enough context, and establishes boundaries before urgency distorts the conversation.

Start with a monitored contact, expiry date, preferred languages, and canonical URL. Add a short policy when you are ready, test the path from the public internet, and schedule renewal. If you maintain a personal website, check whether your own /.well-known/security.txt exists today. Share what you include in it, or the difficulties you encounter, in the comments so other small-site owners can build a clearer front door too.