Loading...
Loading...
security.txt is a plain-text file at `/.well-known/security.txt` (RFC 9116) that tells security researchers exactly how to report a vulnerability to you: who to contact, your disclosure policy, and how to encrypt the report.
This is a best-practice gap, not an exposure. A missing security.txt opens no attack path and leaks nothing. What it costs you is a clear reporting channel. A researcher who finds a flaw has to guess where to send it: a generic info@ inbox that never gets read, a sales contact form, a LinkedIn message, or worst case, full public disclosure or a post on social media because they could not find you. A machine-readable, well-known contact shortens the path from discovery to fix and signals that you welcome reports. Bug-bounty triage tools and vulnerability-disclosure frameworks increasingly check for it, and EU CRA readiness checklists reference it as evidence of a coordinated disclosure process.
RFC 9116 defines exactly two mandatory fields. `Contact` gives at least one reporting method as a URI (`mailto:`, `tel:`, or `https:`) and may appear multiple times in preference order. `Expires` is a single RFC 3339 timestamp (`YYYY-MM-DDTHH:MM:SSZ`) that must be in the future; the RFC recommends setting it less than a year out so a stale file is obvious. Optional fields include `Canonical`, `Encryption`, `Policy`, `Acknowledgments`, `Preferred-Languages` (RFC 5646 tags), and `Hiring`. The file MUST be served over HTTPS from `/.well-known/security.txt` (RFC 8615 well-known URI) with `Content-Type: text/plain; charset=utf-8`. A root-level `/security.txt` is legacy only, and if both exist the one under `/.well-known/` wins. RFC 9116 RECOMMENDS an OpenPGP cleartext signature so a researcher can detect a tampered contact address; when you sign, add a `Canonical` field so the signature also authenticates the file location.
security.txt is a plain-text file served over HTTPS at `/.well-known/security.txt`. A missing file, an HTTP-only file, a wrong content type, or a past `Expires` date are all findings. The root path `/security.txt` is legacy: if you serve there, also serve (and prefer) the `/.well-known/` copy.
curl -s https://yourdomain.com/.well-known/security.txtcurl -sI https://yourdomain.com/.well-known/security.txthttps://securitytxt.org/No. Missing security.txt exposes nothing and opens no attack path, which is why it is rated Low. It is a reporting-channel gap: without it, a researcher who finds a real bug may not know how to reach you, which delays or discourages disclosure.
No, the signature is RECOMMENDED, not required. A valid file needs only `Contact` and `Expires`. Signing lets researchers detect a tampered contact address if your web server is compromised, so it is worth doing once your process is stable. If you do sign, keep the signature valid or remove it.
At `https://yourdomain.com/.well-known/security.txt`, served over HTTPS as `text/plain; charset=utf-8`. The `.well-known/` directory is the RFC 8615 standard location. A copy at the root is allowed for legacy clients, but the `.well-known/` one is authoritative.
A single RFC 3339 UTC timestamp in the future, for example `2026-12-31T23:59:59Z`. RFC 9116 recommends less than a year out so an abandoned file becomes obvious. Set a calendar reminder to renew it.
Applied the configuration change? Run a live scan to confirm the vulnerability is patched.