Security.txt RFC-9116 Policy Document Builder
Generate RFC 9116 compliant security.txt policy documents with live validation, PGP key integration, and CSAF endpoints.
RFC 9116 Policy Directives
Must be a future date in UTC format. Maximum recommended validity is 1 year.
Generated security.txt Output
RFC 9116/.well-known/security.txt
# security.txt - RFC 9116 compliant vulnerability disclosure policy # https://www.twistertools.com/tools/web-tools/security-txt-generator Contact: mailto:security@example.com Expires: 2027-03-16T00:00:00Z Encryption: https://example.com/pgp-key.txt Acknowledgments: https://example.com/hall-of-fame Policy: https://example.com/security-policy Preferred-Languages: en, es, fr Canonical: https://example.com/.well-known/security.txt
Deployment Requirement: Upload this document to the top-level directory at https://yourdomain.com/.well-known/security.txt. Ensure the web server returns the Content-Type: text/plain; charset=utf-8 header and serves the file over HTTPS with a valid certificate.
The RFC 9116 Standard: Establishing Coordinated Vulnerability Disclosure
Published by the Internet Engineering Task Force (IETF) in April 2022, RFC 9116 formalized the security.txt specification into an official Internet Proposed Standard. When security researchers discover critical vulnerabilities such as SQL injection, cross-site scripting, or remote code execution, identifying the appropriate technical personnel without triggering legal misunderstandings has historically been challenging. The security.txt document provides an unambiguous, automated pathway for vulnerability reporting.
Direct Response Channels
Eliminates delays by steering disclosure reports away from general marketing inboxes or customer support tiers straight into product security incident response teams (PSIRT).
End-to-End Encryption
The Encryption directive allows ethical researchers to encrypt proof-of-concept exploits using your verified PGP public key before transmitting sensitive details over email.
Safe Harbor Protection
Linking to a formal Vulnerability Disclosure Policy establishes clear legal safe harbors under CFAA and DMCA laws for researchers operating in good faith.
Comprehensive RFC 9116 Directive Dictionary
| Directive | RFC Status | Specification Standard & Usage |
|---|---|---|
| Contact | Mandatory | URI to report vulnerabilities (mailto:, https://, or tel:). At least one is strictly required. |
| Expires | Mandatory | ISO 8601 UTC date and time when the policy expires. Maximum interval must not exceed 1 year. |
| Encryption | Optional | Points to an OpenPGP public key (HTTPS URL, openpgpkey, or DNS TXT record). |
| Acknowledgments | Optional | Link to a Hall of Fame page recognizing ethical researchers who have responsibly disclosed bugs. |
| Policy | Optional | Link to the organization's vulnerability disclosure terms, testing scope, and safe harbor terms. |
| Hiring | Optional | Direct link to security and engineering career listings for researchers reviewing your site. |
| CSAF | Optional | Machine-readable Common Security Advisory Framework provider metadata endpoint. |
| Preferred-Languages | Optional | Comma-separated list of RFC 5646 language tags supported by the security triage team. |
| Canonical | Optional | The canonical HTTPS address where this security.txt document is permanently maintained. |
Production Deployment Recipes: Nginx, Apache, and Next.js
RFC 9116 requires that the file be served over TLS/HTTPS with a Content-Type: text/plain; charset=utf-8 MIME header. Below are sample configurations for standard web infrastructure:
location = /.well-known/security.txt {
default_type text/plain;
add_header Content-Type "text/plain; charset=utf-8";
allow all;
}<Files "security.txt">
ForceType text/plain
Header set Content-Type "text/plain; charset=utf-8"
</Files>// Place directly in: public/.well-known/security.txt // Next.js serves files from // public/ automatically.
Cryptographic Integrity: Signing security.txt with GnuPG
To prevent man-in-the-middle attacks or tampered content resulting from content delivery network (CDN) compromise, RFC 9116 §5 recommends creating an OpenPGP cleartext signature over your security.txt document. Execute the following GPG terminal commands on your administrative workstation:
# 1. Generate an OpenPGP cleartext signature over security.txt
gpg --clearsign --armor --output security.txt.signed security.txt
# 2. Rename signed file to production filename
mv security.txt.signed security.txt
# 3. Verify signature validity against your public key
gpg --verify security.txt
Frequently Asked Questions (FAQ)
What is RFC 9116 security.txt and why is it needed?
RFC 9116 specifies a standardized machine-readable text file hosted at /.well-known/security.txt. It allows white-hat security researchers and ethical hackers to easily locate the appropriate reporting channel when discovering vulnerabilities in your web services without searching for obscure contact forms.
Where must the security.txt file be hosted on my web server?
Under RFC 9116 §3, the file MUST be accessible via HTTPS under the path ‘/.well-known/security.txt’. While placing a copy at ‘/security.txt’ was historically supported as a backward-compatibility fallback, modern automated scanners and bug bounty platforms look strictly at the /.well-known/ standard URI.
Which directives are mandatory in a valid security.txt document?
RFC 9116 requires two directives: Contact (providing a valid mailto: or https:// link to submit vulnerability reports) and Expires (an ISO 8601 timestamp strictly in the future indicating when the policy document expires and requires scheduled audit or renewal).
Why is an Expires directive required, and how long should it be?
The Expires directive ensures stale or abandoned contact emails are not used by researchers. RFC 9116 recommends that the expiration date should not exceed one year in the future, with 3 to 6 months being the recommended enterprise practice to ensure periodic reviews of contact channels.
Should the security.txt file be cryptographically signed?
Yes. RFC 9116 strongly recommends signing the security.txt file using an OpenPGP cleartext signature (RFC 4880). This prevents malicious actors or compromised CDNs from substituting legitimate vulnerability reporting addresses with attacker-controlled endpoints.
What is the CSAF directive in RFC 9116?
The CSAF directive points to the machine-readable Common Security Advisory Framework provider-metadata.json file, allowing automated threat intelligence aggregators and vulnerability scanners to ingest your organization's formal security advisories.
Related & Complementary Utilities
Explore more privacy-first client-side web tools.
Open Graph Meta Tag Generator & Social Card Suite
Build Facebook, LinkedIn, and social media Open Graph tags. Preview rich card images, post titles, and descriptions prior to publishing.
What Is My IP Address & Network Inspector
Check your public IPv4/IPv6 address, ISP details, geolocation, and connection security in real time.
Content Security Policy (CSP) Header Generator
Generate hardened Content Security Policy Level 3 headers with presets for Next.js, WordPress, and zero-trust security.