security.txt: The File That Tells Researchers How to Report a Vulnerability

Imagine a security researcher finds a real vulnerability on your website. They want to report it responsibly — but there's no obvious email, no bug bounty page, nothing. What happens next is largely down to chance, and it isn't always in your favor.

What security.txt Solves

Defined in RFC 9116, security.txt is a plain text file placed at a standard location (/.well-known/security.txt) that tells anyone exactly how to report a security issue: a contact email or URL, optionally a PGP key for encrypted reports, and an expiry date so the information stays current.

Why This Actually Matters

Without a clear reporting path, researchers who find something serious often either give up on responsible disclosure entirely, or post their findings publicly out of frustration — both worse outcomes than a quiet, coordinated fix that never becomes public.

It Costs Almost Nothing to Add

Unlike most security controls, security.txt requires no code changes, no infrastructure, and no ongoing maintenance beyond updating the expiry date occasionally. It's a five-minute addition with a real, if hard-to-quantify, upside.

Common mistakes

Publishing a security.txt file with an outdated or unmonitored contact email — a researcher who reports a real vulnerability to an inbox nobody checks gets no response, which sometimes pushes well-intentioned researchers toward public disclosure out of frustration, the exact outcome the file was meant to prevent.

Placing the file only at the root (`/security.txt`) and not at the required `/.well-known/security.txt` location specified in RFC 9116 — automated tools and many researchers check the well-known path first and may never find a root-only copy.

Check If a Site Has One

Nexora Shield's security.txt Checker verifies whether a domain publishes a valid file and whether it follows the RFC 9116 format correctly.