ZenovayTools

Security.txt Checker

Validate your security.txt file against RFC 9116. Checks required fields (Contact, Expires), optional fields (Encryption, Policy, Canonical), expiry status, and HTTPS hosting. Get a health score and actionable recommendations.

How to Use Security.txt Checker

  1. 1Enter a domain name (e.g., example.com).
  2. 2The tool fetches /.well-known/security.txt and /security.txt.
  3. 3Fields are parsed and validated against RFC 9116 requirements.
  4. 4Review the health score, any issues found, and recommendations.
Zenovay

Privacy-first analytics for your website

Understand your visitors without invasive tracking. GDPR compliant, lightweight, and powerful.

Explore Zenovay

Related Tools

Password GeneratorGenerate strong, random passwords with customizable length, characters, and complexity.
Password Strength CheckerCheck how strong your password is. Get an estimated crack time and improvement suggestions.
HMAC GeneratorGenerate HMAC signatures using SHA-256, SHA-384, or SHA-512 with the Web Crypto API.
AES Encryption/DecryptionEncrypt and decrypt text using AES-GCM with PBKDF2 key derivation. Runs entirely in your browser.

Frequently Asked Questions

What is security.txt and why does it matter?▾
security.txt is a text file placed at /.well-known/security.txt on a website that tells security researchers how to responsibly disclose vulnerabilities. Standardized in RFC 9116, it provides contact information, disclosure policy, encryption keys, and an expiry date. Without it, researchers may not know how to reach your security team, potentially leaving vulnerabilities unreported or publicly disclosed.
What fields are required in security.txt?▾
RFC 9116 requires two fields: (1) Contact: at least one contact method (mailto:, https://, or tel: URI), and (2) Expires: an ISO 8601 date/time when this file should be considered stale. All other fields are optional but strongly recommended: Encryption (PGP key URL), Policy (disclosure policy URL), Canonical (the canonical URL of this file), Preferred-Languages, Acknowledgments, Hiring, and CSAF.
Where should security.txt be placed?▾
The preferred location per RFC 9116 is /.well-known/security.txt (e.g., https://example.com/.well-known/security.txt). The legacy location /security.txt is also supported for backwards compatibility. The file must be served over HTTPS. If both locations exist, /.well-known/security.txt takes precedence.
How long should security.txt be valid?▾
RFC 9116 recommends setting the Expires field to no more than one year in the future. A shorter validity (e.g., 90-180 days) forces regular review and ensures contact information stays current. Expired security.txt files are treated as if no file exists, so set up reminders to renew. Many teams set it to exactly one year and renew annually.
Should security.txt be PGP-signed?▾
PGP signing is optional but recommended for high-security environments. A signed security.txt lets researchers verify the file has not been tampered with — an attacker who compromises your web server could otherwise replace your security.txt with a different contact address. Sign with your security team's PGP key and link to the public key using the Encryption field.