A security.txt file publishes a standard, machine-readable location for security researchers to report a real vulnerability responsibly, instead of guessing at a contact method or giving up and not reporting it at all. Without one, someone who finds a genuine issue on your site has no clear way to reach you, and no easy way for you to know a real problem exists before it gets exploited.
The standard behind it
This isn’t a proprietary format, security.txt is defined by RFC 9116, an official internet standard published through the IETF, the same body responsible for the core protocols the web runs on. Following the actual standard rather than an improvised version means security tools and researchers who specifically look for this file know exactly what to expect from it.
What the file actually needs to contain
At minimum, a Contact field (an email address or a URL where reports can be submitted) and an Expires field (a date after which the file should be considered stale and needs updating, part of the standard specifically to prevent an abandoned, years-old contact from misleading someone). The security.txt project’s official site, run by the standard’s original authors, has a generator tool if you’d rather not hand-write the file. A minimal working example:
Contact: mailto:security@yoursite.com
Expires: 2027-01-01T00:00:00.000ZOptional but genuinely useful additional fields include Encryption (a link to a PGP key if you want reports encrypted), Preferred-Languages, and Policy (a link to your actual disclosure policy, if you have one, covering what a researcher can expect in terms of response time and whether you offer any kind of reward).
Method 1: a security plugin
Many WordPress security plugins, including SecondGate, include a security.txt field directly in settings, generate the properly formatted file, and publish it at the correct URL automatically, no manual file placement needed.
Method 2: manual placement
The file needs to be publicly accessible at yoursite.com/.well-known/security.txt, specifically the .well-known path defined by RFC 8615, the separate standard governing well-known URIs generally, not just anywhere on the site. If you’re placing it manually via FTP or your host’s file manager, create a .well-known folder in your site’s root directory if it doesn’t already exist, and place the security.txt file inside it.
Verify it’s actually accessible
Visit yoursite.com/.well-known/security.txt directly in a browser after setting it up, confirming it loads as plain text rather than returning a 404. Some hosting configurations block access to dot-prefixed folders like .well-known by default for unrelated reasons, worth checking specifically if the file doesn’t load even though you’ve confirmed it’s genuinely there.
Set a calendar reminder for the expiry date
Since the standard specifically requires an Expires date, and a stale, long-expired file signals the contact information may no longer be current, set a reminder to update this file (even if nothing else about it changes) before that date arrives, rather than letting it quietly go stale.
Where this fits into a broader security setup
A security.txt file doesn’t prevent an attack on its own, it’s about giving a legitimate researcher a responsible path to tell you about a real problem before it’s exploited by someone less well-intentioned. For the complete picture, how to secure a WordPress site covers the protections that actually reduce your attack surface in the first place.
