Adding security.txt in 5 minutes — a vulnerability disclosure starter | Scanthra

Scanthra · 6 min read · Updated May 2026

What security.txt actually is

security.txt is a small, machine-readable plain-text file you publish on your website. It is the security world's equivalent of robots.txt: a known location, a simple syntax, and a clear purpose. Its job is to answer one question for someone who thinks they've just found a vulnerability on your site — "who do I tell, and how?"

The format is standardised in IETF RFC 9116 ("A File Format to Aid in Security Vulnerability Disclosure"). It became a Proposed Standard in 2022, so it is no longer a draft or a quirk — it's the agreed way to do this.

Why it matters even if you're not a bank

Three reasons it's worth the five minutes:

• Researchers can reach you. Without a clear channel, well-meaning finders either give up, post the issue publicly, or spray-and-pray your generic contact form. A documented address catches the problem early, privately.
• Procurement and questionnaires expect it. Vendor security questionnaires (SIG, CAIQ, custom enterprise ones) and EU NIS2-shaped checklists increasingly ask "do you publish a vulnerability disclosure policy?". A live security.txt is the cheapest possible "yes".
• It signals maturity. A site with a current security.txt looks like one whose owner has thought about what happens when something goes wrong. That alone moves you out of the bottom quartile.

The fields RFC 9116 defines

Only Contact and Expires are required. The rest are optional but useful.

• Contact: — required. One or more ways to reach you: an email (prefixed with mailto:), a phone number (tel:), or a reporting URL (https://). Multiple Contact lines are allowed; list them in order of preference.
• Expires: — required. An ISO 8601 timestamp after which this file should no longer be trusted. Most teams set it 6–12 months in the future and refresh it on a calendar reminder.
• Encryption: — a URL to your PGP public key, if you want encrypted reports. Optional but appreciated.
• Acknowledgments: — a URL to a page that thanks researchers who've reported issues responsibly. Cheap good karma.
• Preferred-Languages: — comma-separated BCP 47 language tags (for example en, de, pl). You can omit it — most teams understand English plus their own language anyway.
• Canonical: — the canonical URL of this file. Useful if your site is reachable on multiple hostnames; it tells parsers which copy is authoritative.
• Policy: — a URL to your full vulnerability disclosure policy: scope, safe-harbour language, expected response time.
• Hiring: — a URL to your security-team jobs page. Yes, it's in the spec.
• CSAF: — a URL to a CSAF 2.0 provider metadata file. Only relevant if you publish machine-readable advisories; small businesses can ignore it.

A copy-paste sample you can actually use

Replace the email, dates and URLs with your own. Keep the file plain ASCII (no BOM) and use UNIX line endings. Lines starting with # are comments.

# security.txt for example.com
# Please report security issues using the contacts below.

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

Where to put it

The canonical location is:

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

The legacy location /security.txt at the document root is also tolerated by most tools, but the /.well-known/ path is the one RFC 9116 prescribes — use that.

nginx

location = /.well-known/security.txt {
    alias /var/www/example.com/.well-known/security.txt;
    default_type text/plain;
    add_header Cache-Control "public, max-age=3600";
}

Apache

<Files "security.txt">
    ForceType text/plain
    Header set Cache-Control "public, max-age=3600"
</Files>

Just place the file at /var/www/example.com/.well-known/security.txt and make sure Apache is allowed to serve hidden directories (some default configurations block .-prefixed paths).

Static hosts, WordPress, Cloudflare Pages, Vercel, Netlify

Drop a file named security.txt into a folder named .well-known in your public assets directory and redeploy. Most static hosts serve dotfile directories happily; check by visiting the URL right after deployment.

Sign it (optional but tidy)

RFC 9116 allows the file to be a clearsigned PGP message. Most small businesses don't bother — and that's fine. If you already publish a PGP key, signing makes it harder for someone to spoof the file via a compromised host. If you don't, skip it; an unsigned file is perfectly valid.

Common mistakes worth avoiding

• Missing Expires. An expired or absent Expires line makes the file invalid per the spec. Parsers will warn or reject it.
• Wrong MIME type. The file must be served as text/plain; sometimes a web server returns application/octet-stream and breaks parsing.
• HTTPS-only. security.txt must be served over HTTPS on its canonical URL. A plain-HTTP version is ignored.
• Personal inbox in Contact. Use a role address like security@ that survives staff changes, not jane@.
• Forgotten renewal. Put the Expires date on the same calendar you renew TLS certificates on. An expired security.txt is worse than none — it tells researchers the team is asleep.

How Scanthra detects this

Our M10 robots and well-known probe checks whether /.well-known/security.txt exists and is reachable on the canonical HTTPS URL. If it's missing we surface a low-severity observation rather than a finding — it's a "nice to have, not a wound" — and we include this guide as the suggested fix. Sites that already publish a valid file get a quiet thumbs-up in the compliance map.