Security.txt: the 30-second file that tells researchers how to reach you

Picture the good version of getting hacked. A security researcher finds a real bug in your product. Not a criminal, just someone who pokes at things and stumbles into a hole you'd want to know about. Their next move decides how your week goes.

They try to tell you. And they can't find where. There's no security contact on your site, no obvious email, nothing in your DNS, nothing at the one standard path that's supposed to hold this. So they do the next thing: they post it, or they sit on it, or they sell it. The bug was findable either way. The only thing you controlled was whether the finder had a way to reach you, and you didn't give them one.

The actual problem this solves

A stranger pokes at your site and finds something. That part is going to happen, you can't opt out of being on the internet. What you can decide is what happens in the 10 minutes after.

Right now, a well-meaning researcher hits a wall. Your "Contact us" form routes to sales. Your support email auto-replies with a ticket number and a 48-hour SLA. There's no security@ address published anywhere, no policy page, nothing telling them you even want the report. Every minute of friction makes the worse outcome more likely. People take the path of least resistance, and if the path to you is harder than tweeting about it, they tweet.

security.txt removes the wall. It's a plain text file at a fixed, predictable location that says "here's how to report a security issue to us, and here's how we'll respond." A researcher who finds a problem checks for it by reflex. It is defined in RFC 9116, so it's a real standard that researchers already know to look for.

What the file is and where it goes

It lives at /.well-known/security.txt, served over HTTPS. That path is the whole point: a researcher doesn't have to guess your contact flow, they request the same path on your site that they'd request on anyone's. Here's a complete, valid file.

Contact: mailto:[email protected]
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: en
Canonical: https://yourdomain.com/.well-known/security.txt
Policy: https://yourdomain.com/security-policy

Two fields carry the weight. Contact is the address or URL a report goes to, and it's the only required field. Expires is a date after which the info shouldn't be trusted, which forces you to keep it current instead of leaving a dead security@ address pointing nowhere in three years. The rest is polish.

That's it. Drop the file at that path, make sure it returns 200 over HTTPS, and you've turned "I couldn't find anyone to tell" into "I emailed them and they replied." Thirty seconds, and it can be the difference between a quiet fix and a public disclosure.

It won't stop a single attack, and that's fine

Be clear about what this is, because it's easy to oversell. security.txt does not patch anything. It does not block a request, harden a header, or close a hole. A 200 on /.env is just as exposed whether or not you publish a contact file, so this is not a substitute for the pre-launch pass that actually finds your holes.

What it changes is the path a report takes when someone finds a hole anyway. And someone will. It points the good actors at your inbox instead of at the timeline. That's a smaller claim than most security advice makes, and it's true, which is worth more.

A missing file also reads as a signal. A researcher who finds no security.txt, no security@, and no policy page often reads it the way you'd read a shop with no "we're open" sign: maybe nobody's home, maybe nobody cares. Publishing one says you take reports, you'll respond, and there's a person on the other end. That tone shapes what a finder does with what they found.

Where it sits in the bigger check

Among the things a scan looks at, this is low-severity but pays off out of proportion to the effort. It won't move your grade much. It will quietly improve every future incident you don't yet know about. SurfaceCheckr flags a missing /.well-known/security.txt in the same outside-in pass that catches your exposed files, leaked keys, and DNS gaps, because checking for it is exactly one GET request from outside, the same place a researcher stands.

Honest scope, as always: we tell you the file is missing and what a valid one looks like. We can't tell you whether the address inside it is monitored, that part's on you. For the full picture of what that one external pass covers and what it deliberately doesn't, read what a security scan can and can't tell you.

The bug is going to be found. Decide now whether the finder can reach you.