Security.txt Generator

security.txt

		

	
















FREE TOOL · NO SIGN-UP





This security.txt generator creates a standards-compliant security.txt file that tells security researchers how to report vulnerabilities on your website. Fill in your contact details and an expiry date, add optional policy and encryption links, and copy or download a file that follows RFC 9116. It’s for site owners, developers and IT teams who want a clear, official way for people to report problems before they become incidents.













What security.txt Does





Purpose and RFC 9116





When someone finds a security issue on a website, the hardest part is often finding who to tell. Contact forms go to sales, support emails get ignored, and the report never reaches the right person. security.txt fixes that with a small, plain-text file at a predictable address, https://yourdomain/.well-known/security.txt, listing how to contact your security team.





The format is defined in RFC 9116, published by the IETF in 2022. Each line is a field name, a colon and a value, like Contact: mailto:security@example.com. Lines starting with # are comments. Because the location and format are standard, researchers and automated scanners know exactly where to look.





Required vs optional fields





RFC 9116 makes two fields required:





    

  • Contact: at least one way to reach you, usually a mailto: email or an https:// URL. You can list several, in order of preference.
    • 




  • Expires: the date and time after which the file should be considered stale.
    • 






Everything else is optional: Encryption (a link to your public key), Acknowledgments (a page thanking researchers), Policy (your vulnerability disclosure policy), Hiring (security jobs), Preferred-Languages and Canonical (the official URL of the file).













How to Create a security.txt File





The file preview updates live as you fill in the form.





Step 1 – Add contact methods





Enter one contact per line in Contact. Use a dedicated address such as security@yourdomain.com rather than a personal inbox, so reports survive staff changes. If you type a plain email, the generator adds mailto: for you. You can also add a URL to a reporting form. If you leave this empty, the tool shows a warning, because the file isn’t valid without a contact.





Step 2 – Set an Expires date





Pick a date in Expires. If you leave it empty, the generator uses one year from today. RFC 9116 recommends keeping the expiry less than a year ahead, so choosing a date a few months shorter, and setting a reminder to renew, is a good habit.





Step 3 – Add policy and key links





Add your Policy URL, an Encryption key URL if you accept encrypted reports, and an Acknowledgments URL if you publicly thank researchers. Preferred languages defaults to en; list others separated by commas, such as en, fr. Add the Canonical URL where the file will live.





Step 4 – Upload to /.well-known/





Click Download to save security.txt, or Copy the contents. Upload the file to a folder called .well-known in your site’s root, so it’s reachable at https://yourdomain/.well-known/security.txt. Then open that URL in a browser to confirm it loads as plain text.













Writing a Vulnerability Disclosure Policy





The security.txt file points to your policy. The policy explains the rules.





Scope and safe harbour





Say what’s in scope, for example your main website and API, and what isn’t, such as third-party services you don’t control. Describe what testing is acceptable and what isn’t, like denial-of-service attacks or accessing other users’ data. Many organisations include a “safe harbour” statement, promising not to take legal action against researchers who follow the policy in good faith. That reassurance is often what makes people willing to report at all.





Response times





Tell researchers what to expect after they report: when you’ll acknowledge the report, how you’ll keep them updated and roughly how long fixes usually take. Only promise timelines you can meet. Explain how you handle public disclosure, for example asking researchers to wait until a fix is released, and whether you offer rewards or public credit.













Signing and Canonical URLs





OpenPGP clear-signing





RFC 9116 recommends digitally signing security.txt with an OpenPGP cleartext signature. A signed file lets researchers confirm it really came from you and hasn’t been tampered with. This generator creates the unsigned text. To sign it, run it through a tool like GnuPG with a clear-sign command, then upload the signed version. Make sure the public key is available at the URL in your Encryption field or another trusted place.





Multiple domains





If you run several domains or subdomains, each should serve its own security.txt, or redirect to a main one. The Canonical field lists the URL or URLs where the file is officially published. That helps researchers spot a copied or outdated file on a domain you no longer control.













Hosting on WordPress, Nginx and Apache





Serving the right MIME type





The file should be served as plain text, ideally with the text/plain; charset=utf-8 content type. Most servers do this automatically for .txt files. On WordPress, upload the file to a .well-known folder in the site root using your host’s file manager, SFTP or a plugin that manages well-known files. Some hosts hide folders that start with a dot, so check that the URL loads.





Redirects from root





Older tools sometimes look for /security.txt at the root of the domain. RFC 9116 allows a redirect from that legacy location to the .well-known path. On Apache you can add this in .htaccess, and on Nginx with a simple location block. Our .htaccess Redirect Generator and Nginx Redirect Generator can write the rule for you.













security.txt Mistakes





Expired files





An expired file tells researchers it may not be trustworthy. Put the renewal date in your calendar and update the file before it lapses.





Dead contact addresses





If the contact email bounces or nobody reads it, the file does more harm than good. Test it, and make sure reports reach a monitored team inbox.





Serving over HTTP





RFC 9116 requires security.txt on web servers to be served over HTTPS. A file on plain HTTP can be tampered with, so redirect HTTP to HTTPS.













Give Researchers a Clear Way to Reach You





A small text file can make the difference between a quiet fix and a public incident. Create yours with the security.txt generator, then set up the companion files every site needs with the Robots.txt Generator, redirect legacy paths with the .htaccess Redirect Generator and protect public contact addresses with the Email Obfuscator. There are more technical SEO tools in the FHSEO Hub free SEO tools collection.













Security.txt Generator FAQs









A security.txt file is a plain-text file, defined in RFC 9116, that tells security researchers how to report vulnerabilities on a website. It sits at a standard location and lists contact details, an expiry date and optional links to a disclosure policy, encryption key and acknowledgments page.









security.txt should be placed in the `.well-known` folder at the root of your domain, so it loads at https://yourdomain/.well-known/security.txt. It must be served over HTTPS as plain text. You can also redirect the older root location, /security.txt, to the .well-known version for tools that still check there.









Two fields are required in security.txt: Contact and Expires. Contact gives at least one way to report a vulnerability, such as a mailto email or an HTTPS link. Expires sets the date after which the file is considered out of date. Policy, Encryption, Acknowledgments, Hiring, Preferred-Languages and Canonical are optional.









You should update the Expires date before it passes, and RFC 9116 recommends setting it less than a year into the future. A common approach is to choose a date several months ahead and renew on a schedule. Each renewal is also a good time to check that the contact details still work.









Signing security.txt is recommended but not required. RFC 9116 suggests an OpenPGP cleartext signature so researchers can verify the file is authentic and unchanged. If you sign it, publish the matching public key and link to it in the Encryption field. An unsigned file is still valid.