How to Create a security.txt File

When a security researcher finds a vulnerability in your website, the first thing they need is a way to tell you about it — and far too often, there isn't one. A security.txt file solves exactly that problem. Defined by RFC 9116, it is a small, standardised text file you publish at /.well-known/security.txt that tells researchers, in a clear and machine-readable way, how to report a security issue responsibly. This guide explains what security.txt is, why it matters, every field it can contain, how to create and place it, how to validate it, and the common mistakes to avoid — with a complete example you can adapt.

It fits alongside the detection and hardening guidance in how to tell if a website has been hacked and how to protect your website from common attacks: security.txt is about handling the reports of problems gracefully.

The problem: nowhere to send a report

Imagine a well-meaning researcher discovers a flaw on your site — an exposed endpoint, a misconfiguration, a way to access data they shouldn't. They want to do the right thing and tell you privately so you can fix it before anyone exploits it. But how? They try security@yourdomain.com and it bounces. They hunt through your contact page and find only a sales form. They tweet at you and get no reply. Frustrated, they give up, or post it publicly, or it simply never reaches the people who could act on it.

This is a genuine, everyday failure. The absence of an obvious reporting channel means good-faith vulnerability reports get lost, delayed, or never made at all — which is the opposite of what any site owner wants. The longer a flaw stays unreported, the longer it stays unfixed and exploitable.

security.txt fixes this with a simple convention, much like robots.txt did for crawlers: a predictable, standardised file at a known location that any researcher (or automated tool) can check to find out exactly how you want to be contacted about security issues. It turns "how on earth do I report this?" into a ten-second lookup.

What security.txt is

security.txt is a plain-text file that lives at a standardised path on your domain and contains a set of fields describing your security-contact and disclosure information. It was formalised as RFC 9116 by the Internet Engineering Task Force (IETF), which means it is a recognised, stable standard rather than one vendor's idea — and that is why researchers and tooling can rely on its format.

The canonical location is:

https://example.com/.well-known/security.txt

The .well-known/ directory is the standardised place for this kind of site metadata. (A copy may also be placed at the top level, /security.txt, for legacy reasons, but .well-known is the location that matters.) The file must be served over HTTPS — see what is HTTPS and why your site needs it — because the information in it (where to send sensitive reports) needs to be trustworthy and tamper-evident in transit.

The fields, explained

A security.txt file is a list of Field: value lines. Two fields are required; the rest are optional but useful. Lines beginning with # are comments.

Required fields

• Contact — how to reach your security team. This is the whole point of the file, and you can list more than one, in order of preference. A value can be an email address (mailto:security@example.com), a web form (https://example.com/security-report), or a phone number (tel:+1-201-555-0123). At least one Contact line is mandatory.
• Expires — the date and time after which this file should no longer be considered current. It is given in the standard ISO 8601/RFC 3339 format (for example 2027-01-01T00:00:00.000Z). This required field stops a stale file from being trusted forever; set it a sensible distance in the future (often a year) and diarise updating it before it lapses.

Optional fields

• Encryption — a link to your PGP public key (https://example.com/pgp-key.txt), so a reporter can encrypt sensitive details. Point to the key; do not paste the key into the file itself.
• Policy — a link to your vulnerability disclosure policy, which sets out scope, expectations and safe-harbour terms for researchers. This is one of the most valuable additions.
• Acknowledgments — a link to a page where you thank researchers who have responsibly reported issues. Recognition is a genuine incentive for good-faith reporting.
• Preferred-Languages — the languages your team can handle reports in (for example en, fr), so reporters know how best to write to you.
• Canonical — the canonical URL of the security.txt file itself, which helps confirm authenticity, especially relevant when the file is signed.
• Hiring — a link to security-related job openings. Optional and lightweight, but a common, friendly addition.

Field	Required?	Purpose	Example value
Contact	Yes	How to report a vulnerability	mailto:security@example.com
Expires	Yes	When to stop trusting this file	2027-01-01T00:00:00.000Z
Encryption	No	Link to a PGP key for encrypted reports	https://example.com/pgp-key.txt
Policy	No	Link to your disclosure policy	https://example.com/security-policy
Acknowledgments	No	Page thanking reporters	https://example.com/hall-of-fame
Preferred-Languages	No	Languages you accept reports in	en, fr
Canonical	No	Canonical URL of this file	https://example.com/.well-known/security.txt
Hiring	No	Security job openings	https://example.com/jobs

A complete example

Here is a realistic security.txt file using the common fields. Adapt the values to your own site:

# Our security contact and disclosure information.
# See https://securitytxt.org and RFC 9116 for the format.

Contact: mailto:security@example.com
Contact: https://example.com/security-report
Expires: 2027-01-01T00:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security-policy
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en, fr
Canonical: https://example.com/.well-known/security.txt

That is genuinely all it takes — a handful of lines that transform a frustrating dead end into a clear, welcoming channel for researchers.

How to create and publish it

The mechanics are straightforward:

1. Decide on your contact method(s). Ideally a dedicated, monitored mailbox such as security@yourdomain.com, and/or a reporting form. Make sure whatever you list is actually watched.
2. Write the file with at least a Contact and an Expires line, adding the optional fields that apply to you. The free generator at securitytxt.org will produce a correctly formatted file from a simple form, which is the easiest way to avoid syntax slips.
3. Place it at /.well-known/security.txt. Create the .well-known directory at your site root if it does not exist and put the file inside. (Optionally also place a copy at /security.txt.)
4. Serve it over HTTPS as plain text, on the same domain it concerns, and confirm it loads at https://yourdomain.com/.well-known/security.txt.
5. Optionally sign it with PGP. For higher assurance, you can clear-sign the file with your PGP key so reporters can verify it is authentic and unmodified. If you do, make sure the Canonical and Encryption fields are present and consistent with the signature.

How to validate it

Do not just publish and assume it is correct — validate it:

• securitytxt.org validator. The same site that offers the generator provides a validator that checks an existing file against RFC 9116 and flags problems — a missing or past Expires, a missing Contact, formatting errors, or an unreachable file. This is the authoritative quick check, since securitytxt.org is the reference resource for the standard.
• Fetch it yourself. Request the URL over HTTPS (in a browser, or with curl https://yourdomain.com/.well-known/security.txt) to confirm it is reachable, served as text, and returns the content you expect.
• Verify the signature if you signed the file, checking that it matches the key linked in Encryption.

Broader site audits often note whether a security.txt file is present as part of a wider security and configuration picture — StackOptic among them — which is a handy way to confirm it stays in place over time alongside your headers and HTTPS status.

Why it matters (and what it does not do)

It is worth being precise about the value of security.txt, because it is easy to over- or under-sell.

What it does: it dramatically improves your vulnerability-disclosure process. It gives researchers a clear, trusted, standardised channel, so reports reach the right people quickly instead of bouncing, going to sales, or being abandoned. It signals that you welcome responsible disclosure, which encourages good-faith researchers to come to you privately rather than disclosing publicly. And because it is machine-readable, security tooling and platforms can find your contact automatically. The net effect is to shorten the time a vulnerability stays unreported and unfixed — which is exactly when a flaw is most dangerous.

What it does not do: it does not find or fix vulnerabilities, and merely having the file changes nothing on its own. A security.txt that points to an unmonitored inbox, or that has expired, is worse than useless — it implies a responsiveness you are not delivering. To get the benefit, you must back it with substance: a genuinely monitored contact, ideally a real disclosure policy (the Policy field), and a process to act on reports. Treated as a real commitment rather than a checkbox, it is a low-effort, high-trust addition for any site.

Common mistakes to avoid

• No Expires, or an expired date. It is required, and a lapsed file should not be trusted — set a future date and renew it before it passes.
• An unmonitored Contact. The file is only as good as the inbox behind it; route it to someone who will respond.
• Serving it over HTTP, or on the wrong path. It must be HTTPS and at /.well-known/security.txt.
• Pasting a PGP key into the file. Use the Encryption field to link to the key instead.
• Publishing and forgetting. Revisit it when contacts, policies or keys change, and well before Expires lapses.
• Treating it as a substitute for real security work. It is a disclosure-process signal layered on top of solid fundamentals, not a replacement for them.

A quick security.txt checklist

• Include at least one monitored Contact and a future Expires date.
• Add Policy, Encryption and Acknowledgments where you can — they make the file far more useful.
• Place the file at /.well-known/security.txt and serve it over HTTPS.
• Validate it with the securitytxt.org checker and fetch it to confirm it loads.
• Sign it with PGP for extra assurance if appropriate, keeping Canonical and Encryption consistent.
• Diarise a review so the file never expires unnoticed and the contact stays live.

Go deeper

• Handle the problems that get reported: how to protect your website from common attacks.
• Spot trouble yourself: how to tell if a website has been hacked.
• The HTTPS the file must be served over: what is HTTPS and why your site needs it.
• Harden the rest of the response: HTTP security headers explained.

Want to check whether your site exposes a security.txt, security headers and a valid certificate? Analyse any URL with StackOptic — free, no sign-up.