What is a security.txt file, and how do you publish one?

Published October 7, 2026 · about a 5-minute read

Picture a well-meaning security researcher who just found a real bug on your site. They want to tell you quietly before anyone abuses it. So they look for a security contact — and find nothing. No obvious email, no form, a support desk that routes "I found a vulnerability" to tier-one billing. After twenty minutes they give up, and now your bug gets dropped on social media or sold instead of reported. A security.txt file is the five-minute fix for that exact failure.

What it is

security.txt is a small plain-text file, standardized as RFC 9116, that you publish at /.well-known/security.txt. It tells anyone who finds a security issue exactly how to report it. That's the whole idea: a predictable, machine-findable address for "here's how to reach our security people." Researchers (and their tooling) check for it automatically.

Why bother — it doesn't make you more secure

Let's be honest about what this is and isn't. A security.txt file won't patch a single vulnerability. What it does is change what happens after someone finds one — turning a dead end into responsible disclosure. That's worth real money in avoided incidents: the difference between a quiet email and a public zero-day is often just whether the finder knew where to send it.

It's also increasingly expected. Big organizations publish one, researchers look for one, and some regulatory and procurement frameworks now treat a documented vulnerability-disclosure contact as table stakes. For the effort involved, the goodwill-to-cost ratio is hard to beat.

security.txt doesn't lock a door. It puts up a sign that says "if you find a door open, here's who to tell" — and that sign is the difference between a heads-up and a headline.

The format

Two fields are required; everything else is optional. Minimal, valid, done:

Contact: mailto:security@yourdomain.com
Expires: 2027-10-07T00:00:00.000Z

A fuller one adds useful context:

Contact: mailto:security@yourdomain.com
Contact: https://yourdomain.com/security
Expires: 2027-10-07T00:00:00.000Z
Preferred-Languages: en
Canonical: https://yourdomain.com/.well-known/security.txt
Policy: https://yourdomain.com/security-policy
Acknowledgments: https://yourdomain.com/hall-of-fame

• Contact (required) — a mailto:, https: or tel: URI. List more than one in order of preference if you like.
• Expires (required) — an ISO 8601 date after which the file is stale. RFC 9116 recommends a year or less. A file with no Expires is invalid.
• Policy, Acknowledgments, Encryption, Preferred-Languages, Canonical, Hiring — optional extras that make the process smoother.

How to publish it

1. Create the file and put it at https://yourdomain.com/.well-known/security.txt.
2. Serve it over HTTPS as text/plain (charset utf-8).
3. Optionally redirect the legacy /security.txt path to the .well-known one, and PGP-sign the file if you want finders to verify it's really yours.

That's it. No DNS changes, no server rebuild — just a static file.

The one gotcha: Expires rots

Here's the trap that catches people. Expires is mandatory and it will pass. A security.txt whose Expires date is in the past doesn't just look sloppy — researchers and validators treat it as abandoned, which is arguably worse than having no file at all, because it signals a disclosure process nobody maintains. So whatever date you set, put a reminder to refresh it before it lapses. It's the same quiet-expiry failure mode as a certificate or a DNS record: fine the day you ship it, silently wrong months later.

That's exactly the kind of thing worth an outside pair of eyes. Our free site checker grades your overall posture — TLS, security headers, DNS — and re-checks it over time, so the small hygiene items don't quietly rot while you're not looking.