There’s a part of most websites that rarely gets any attention, yet plays a critical role in how the internet quietly functions: /.well-known/.
Defined in RFC 8615, the /.well-known/ directory is a standardised location for metadata about a site. It’s designed so that both humans and machines know exactly where to look for important information, without guesswork. Think of it as the “front desk” of your website. Not flashy, not interactive, but if it’s missing, everything becomes unnecessarily difficult.
Common examples include:
/.well-known/security.txt– how to report security issues/.well-known/change-password– where users can update credentials/.well-known/openid-configuration– identity provider metadata
The key idea is consistency. No hunting, no guessing URLs, no emailing info@, admin@, and hoping one lands. Just a known path that answers the question: “Where do I go for this?” And when it comes to security, that question matters more than most.
Reporting vulnerabilities shouldn’t feel like a heist movie #
Imagine you’ve discovered a vulnerability in a website. If you’re an ethical hacker, you want to do the right thing. Report it responsibly. Help fix the issue.
If you’re not… well, you’ve got options and the uncomfortable truth is that reporting vulnerabilities is often harder than exploiting them. Computers are on 24/7. “We’re experiencing a larger call volume that typical, wait times may be elongated”. We’ve all experienced this…
- No clear contact details
- Generic inboxes with no response
- Legal ambiguity (“will I get in trouble for this?”)
- No acknowledgement or feedback
It can feel less like responsible disclosure and more like trying to get a message to someone in a locked-down corporate bunker. Somewhere between Mission: Impossible and shouting into the void. This friction creates a big problem:
- Ethical researchers may give up
- Findings may go unreported
- Or worse, vulnerabilities get disclosed publicly or sold
None of these outcomes are ideal. If you make it hard to report issues, you’re not reducing risk. You’re just redirecting it.
This is where security.txt comes in and defined in RFC 9116. It provides a simple, standard way for organisations to publish security contact and policy information. It lives at:
https://example.com/.well-known/security.txt
No guesswork. No detective work. Just a clear, structured file! Imagine that!!!!
Core fields #
A typical security.txt file includes:
Contact
How to report a vulnerability. This can be an email address, a web form, or even a bug bounty platform.
Contact: mailto:security@example.com
Expires
A timestamp indicating how long the file is valid. This prevents stale or abandoned contact details lingering forever.
Expires: 2026-12-31T23:59:59Z
Policy
A link to your vulnerability disclosure policy. This sets expectations for both parties.
Policy: https://example.com/security-policy
Acknowledgments (optional)
A hall of fame for researchers who report issues responsibly.
Encryption (optional)
A public key for secure communication, if sensitive details are being shared.
Why it matters #
It lowers the barrier to doing the right thing. Instead of forcing researchers to improvise, it provides:
- A clear reporting path
- Defined expectations
- A signal that security is taken seriously
It’s not a silver bullet. It won’t stop vulnerabilities. But it improves how they are handled, and that’s often where the real difference is made.
To borrow from The Matrix: you can take the red pill and see how deep the rabbit hole goes, or you can at least leave a note telling people where the entrance is.
My implementation #
In the spirit of practicing what I preach, I’ve implemented a security.txt file for this site.
You can find it here: https://techielab.org/.well-known/security.txt
It’s intentionally simple (much like the author). Do your future self a favour and generate one for your site.
Reply by Email
