Loading security.txt Generator…
A security.txt file is the address a stranger uses to tell you about a flaw. RFC 9116 defines two required fields and seven optional ones; this builds the file in your browser, checks it against those rules, and sends nothing anywhere.
Every value is a URI, so an email address needs mailto: in front of it and a web address must be https.
Generates 2027-02-13T19:12:47Z
RFC 3339, as in 2027-01-01T00:00:00Z.
RFC 5646 tags. The order implies no preference, whatever the field name suggests.
The page saying what is in scope and how long you ask for.
A URI pointing at a key. Never the key itself.
Spelled without an e before the -ments. The other spelling is silently ignored.
Genuinely a field in the RFC.
Where this file is meant to live. It is what stops a signed copy of your file passing as somebody else’s.
Valid against RFC 9116
2 field lines · serve it at /.well-known/security.txt as text/plain; charset=utf-8
For a web service the well-known path is a must. A copy at the top level, /security.txt, is permitted as a fallback for older tooling, and redirecting it to the well-known location keeps one canonical answer.
RFC 9116 § 3
A file served as text/html, or with no charset, is not conforming. Anything that turns a plain file into a rendered page — a static host adding a template around it — breaks it in a way that is invisible in a browser.
RFC 9116 § 3
The file names the address a vulnerability report goes to, which makes it worth tampering with. Fetched over plaintext, the contact address is whatever the network decided it should be.
RFC 9116 § 3
A file on the apex does not speak for a subdomain, and the RFC is explicit that scope is per-host unless a Canonical line says otherwise. An organisation with many hostnames needs the file on each one it wants reports about.
RFC 9116 § 3.1
A cleartext OpenPGP signature lets a reader confirm the file is yours. It only helps alongside a Canonical line, because otherwise a signed copy of your file works just as well on somebody else’s domain.
RFC 9116 § 2.3
ContactrequiredrepeatableThe only field besides Expires that must be present. A value is a URI, so an email address needs its mailto: scheme, a phone number needs tel:, and a reporting form needs the full https URL. More than one line is allowed and they are read in the order given, so put the address a stranger should try first at the top.
RFC 9116 § 2.5.3
Expiresrequiredonce onlyThe field that surprises people. It is required, it may appear only once, and a researcher is told to treat everything in an expired file as stale — which turns an abandoned security.txt into a dead end rather than a wrong address. A timestamp less than a year out is recommended, which is really a request that somebody look at the file annually.
RFC 9116 § 2.5.5
EncryptionoptionalrepeatableA pointer to a key, never a key. Pasting an ASCII-armoured PGP block into the file is specifically not allowed: the value has to be a URI, which may be an https URL, a dns: URI for an OPENPGPKEY record, or an openpgp4fpr: fingerprint.
RFC 9116 § 2.5.4
AcknowledgmentsoptionalrepeatableSpelled the American way, with no "e" before the "-ments" — a detail worth checking, because the misspelling is silently ignored rather than reported. It is the cheapest thing on this list to provide and the one that most changes how a first-time reporter feels about approaching you.
RFC 9116 § 2.5.1
Preferred-Languagesoptionalonce onlyA comma-separated list of RFC 5646 tags on a single line; a second Preferred-Languages line makes the file invalid. The order carries no meaning at all, which the RFC says explicitly, so listing English first does not make it preferred.
RFC 9116 § 2.5.8
CanonicaloptionalrepeatableThis is what makes a signature worth having. A reader checking the signature also checks that the URL it was fetched from appears here, so a copy of your file dropped on somebody else’s site does not pass as yours.
RFC 9116 § 2.5.2
PolicyoptionalrepeatableThe page that says what is in scope, what you will not take action over, and how long you ask for before publication. Its absence is the most common reason a researcher hesitates: without it they cannot tell whether testing you is welcome.
RFC 9116 § 2.5.7
HiringoptionalrepeatableGenuinely in the RFC, and it exists because the audience reading this file is precisely the audience a security team wants to hire. Harmless to leave out.
RFC 9116 § 2.5.6
Somebody has found a flaw in your service and wants to tell you. The next few minutes decide everything: if the only route they can find is a sales enquiry form, or a support queue that closes their message as a bug report, a fair number give up and a smaller number publish instead. RFC 9116 exists to make that search take five seconds.
It defines a plain text file of colon-separated fields, published at a known path, saying where to send a report and where to read your policy. Field names are case-insensitive, lines beginning with a hash are comments, and any field a reader does not recognise must be ignored rather than treated as an error. That last rule is why a misspelled field name fails silently instead of loudly.
Contact must always be present, and may appear more than once, with the address you would rather be used listed first. Every value is a URI, so an email address needs mailto: in front of it and a reporting form has to be an https URL — plain http is not permitted for a file whose whole purpose is to be trusted.
Expires is the field that catches people out, because it was added late and most examples on the web predate it. It must be present, it must appear exactly once, and it is an RFC 3339 timestamp rather than a date. Under a year into the future is recommended, and the recommendation is really a request that somebody looks at the file annually to check the addresses still reach a person.
Policy is the one to add next. It links to the page saying what is in scope, what you will not pursue anyone over, and how long you ask for before publication — and its absence is the most common reason a researcher hesitates, because without it they cannot tell whether testing you is welcome or actionable.
Encryption points at a key and never contains one: an armoured block pasted into the value is specifically disallowed. Preferred-Languages goes on a single line, and its order carries no meaning despite the name. Acknowledgments links to a page naming people who have reported to you, and it changes how a first-time reporter feels about approaching you. Hiring is genuinely in the specification, on the reasoning that whoever reads this file is who a security team wants to employ.
For a web service the file must sit at /.well-known/security.txt, served over HTTPS as text/plain with a utf-8 charset. A copy at the top level is permitted for older tooling, and redirecting it to the well-known path keeps one canonical answer.
Two deployment mistakes are common enough to check for deliberately. A static host that wraps everything in a template turns the file into HTML, which looks fine in a browser and fails every parser. And the file speaks for the host it is served from, so an organisation with many hostnames needs it on each one it wants reports about.
Signing the file with a cleartext OpenPGP signature is recommended, and on its own it proves less than it appears to. A signed file copied onto another domain still verifies, because the signature attests to the bytes and not to where they were found.
Canonical is what closes that. It names the URIs the file is meant to be served from, so a reader checking the signature also checks that the address it fetched matches one of them. Sign without Canonical and you have proved authorship of a document that anybody may republish as their own.
No, and saying so is useful. A Policy page that states plainly there is no reward, that reports are read by a person, and how long you ask for before disclosure, is more valuable to a researcher than money they were not expecting anyway.
Nothing breaks, but researchers are told to treat the data in an expired file as no longer valid. The result is worse than a typo: the file is still live and parseable, and it is asking to be disregarded by exactly the person you wanted to hear from.
The well-known path is the requirement for a web service; the root copy exists only as a fallback for tooling that has not caught up. Publish at the well-known location and redirect the root one to it if you want both to work.
The American one, with no e before the -ments. The other spelling is not an error a reader reports, because unknown fields must be ignored, so a British-spelled line simply sits in the file being read by nothing at all.