What is security.txt and how it helps people report vulnerabilities

A security.txt file tells researchers exactly how to reach you when they find a vulnerability - a single, standard place for a contact address that turns a lucky report into a reliable one. SecRift checks that yours is present, valid, and in date.

When someone spots a security flaw in your site, the hard part is often just finding out who to tell. security.txt fixes that by putting a machine-readable contact address at a predictable location, so a researcher never has to guess. This guide explains what a security.txt file is, how it works, where it goes wrong, and how SecRift checks yours.

What is security.txt?

security.txt is a small text file, defined by RFC 9116, that publishes how to report a security problem with your domain. It lives at a fixed path - https://example.com/.well-known/security.txt - so security researchers, bug-bounty hunters, and automated tools all know where to look without hunting through your site for a contact page.

Think of it as the digital equivalent of a “in case of emergency, call this number” sticker. It doesn’t fix vulnerabilities or block attacks. What it does is remove friction from the one moment that matters most: when a well-meaning outsider is holding a finding and trying to reach the right person before someone with worse intentions does.

A minimal file looks like this:

Contact: mailto:[email protected]
Expires: 2026-12-31T23:59:59Z

How security.txt works

The file is plain text, served over HTTPS, with one field per line in a Name: value format. RFC 9116 defines a handful of fields, but two are the backbone:

• Contact - required, and the whole point of the file. It’s a URI a researcher can use to reach you: a mailto: address, a tel: number, or an https:// link to a disclosure form. You can list more than one, in order of preference.
• Expires - also required. It’s a date, in RFC 3339 format with an explicit timezone (for example 2026-12-31T23:59:59Z), after which the file should no longer be trusted. It forces you to revisit the file and keep its contents current.

Several optional fields build on that base. Canonical states the URL where the file officially lives, so a copy found elsewhere can be checked against the original. Preferred-Languages lists the languages your team reads. Encryption, Policy, and Acknowledgments point to a public key, your disclosure policy, and a hall of fame respectively.

The canonical location is /.well-known/security.txt - the .well-known directory is a standard place for machine-readable metadata about a site. An older convention put the file at the domain root (/security.txt), and some tools still check there, but the .well-known path is the one the standard requires.

Why security.txt matters

Most vulnerabilities that get reported responsibly are found by people who have no relationship with you - a researcher poking at a login form, a customer who noticed something odd, a scanner that flagged an exposure. For that report to reach you, they need a channel, and every minute spent searching for one is a minute the issue stays open.

A clear security.txt file shortens that path to seconds. It also signals that you take disclosure seriously, which makes researchers more likely to come to you first instead of going public or walking away. And because the file names a dedicated contact, reports land with the team that can act on them rather than in a general support queue.

The flip side is that a stale file is worse than none. An Expires date in the past, or a contact address that bounces, tells a researcher the file is abandoned - and they may give up rather than dig further. That’s why the standard builds in an expiry date: the file is only useful if it’s kept alive.

Common security.txt mistakes

• No Expires field, or an expired one. The date is required, and once it’s in the past the whole file should be treated as untrusted. A file that expired a year ago reads as neglected.
• A contact that doesn’t work. A mailto: to an unmonitored inbox, or a link to a page that no longer exists, defeats the entire purpose.
• Served as HTML, not text. If the path returns your app’s index.html instead of text/plain, no tool can parse it - functionally the same as having no file at all.
• Only at the legacy path. A file at /security.txt but not at /.well-known/security.txt misses the location the standard requires.
• Not served over HTTPS. The file, and any web contact URL inside it, must use HTTPS so its contents can’t be tampered with in transit.
• A Canonical that points elsewhere. If the Canonical field lists a URL that isn’t where the file actually lives, a researcher can’t confirm they’re reading the real thing.

How SecRift checks security.txt

SecRift fetches your security.txt the way a researcher’s tooling would - over HTTPS, at the canonical path first - and breaks the result into four findings:

• Presence - confirms the file is served at /.well-known/security.txt over HTTPS as text/plain. If it’s only at the legacy /security.txt path, that’s flagged as a minor issue; if HTTPS returns an application page or nothing at all, the file is treated as not usable.
• Contact - checks that at least one Contact field holds a valid URI, and that any web contact uses https:// rather than http://. A file with no working contact loses full credit for this finding, because a report has nowhere to go.
• Expires - checks that there’s exactly one Expires field, that it’s a valid RFC 3339 date-time with a timezone, that it hasn’t passed, and that it isn’t set absurdly far in the future. A missing, duplicated, malformed, or expired date loses full credit here.
• Canonical - if the Canonical field is present, confirms it lists the URL the file was actually retrieved from, and checks that Preferred-Languages appears at most once. Canonical is optional, so a file without it still passes.

Each finding comes with a plain-language summary and, where something is wrong, one concrete fix. Because security.txt is an optional, advisory file, SecRift never caps an otherwise-strong domain’s grade over it - a flawed file costs points on this check, but it won’t drag down a domain that’s done everything else right. SecRift reads only what you publish over HTTPS, so the result reflects exactly what a real reporter would find.

security.txt is served from the same /.well-known/ HTTPS location as your MTA-STS policy - two small published files that together tell the outside world how to reach you securely.

Run a free scan on any domain at secrift.com and see your security.txt posture in seconds.