Loading tool...
Create an official, standardized vulnerability disclosure manifest for your website. Empower ethical security researchers and bug bounty hunters to report security bugs privately before they become public exploits.
RFC 9116 Required & Optional Fields
Use an email with mailto: (e.g. mailto:security@example.com) or a web form URL with https://.
Must be in the future (typically 1 year ahead). Prevents abandoned domains from advertising stale security contact addresses.
What it is: A link to your public OpenPGP key so reporters can encrypt vulnerability details. Leave empty if you don't use PGP.
What it is: Link to your Vulnerability Disclosure Policy (Safe Harbor, response time commitment). Leave blank if not available.
What it is: A public webpage where you publicly thank and credit ethical researchers who helped fix security flaws. Leave empty if you don't have one.
What it is: Link to your career page for hiring security professionals. Leave empty if not hiring.
Language codes for security reports (e.g. en for English).
/.well-known/security.txtsecurity.txt file./.well-known/security.txtHTTP 200 OK and Content-Type: text/plain.This tool strictly implements the official securitytxt.orgspecification by Edwin van Andel & Yevgeny Pats, approved by the IETF in RFC 9116.
security.txtIn May 2022, the Internet Engineering Task Force (IETF) officially published RFC 9116 as the global Internet standard for vulnerability disclosure. Here is a plain-English explanation of what each field does and whether your site needs it:
The only strictly required field besides Expires. Gives researchers your direct email (mailto:) or web reporting form (https://).
Mandatory ISO 8601 date. Ensures old or unmonitored security contact addresses are not treated as active indefinitely.
Link to your public PGP key. Allows bug bounty hunters to encrypt sensitive vulnerability details. Leave empty if you don't use PGP.
Link to your Vulnerability Disclosure Policy. Outlines your safe harbor rules, response times, and testing guidelines.
Link to your security acknowledgment page where you credit white-hat hackers who helped protect your users.
Link to security engineering job openings. Security researchers who inspect your site often make great hiring candidates.
Simply leave those fields blank in our generator! RFC 9116 only requires the Contact and Expires fields. A minimal file with just your contact email and expiration date is 100% valid and compliant.
According to RFC 9116 Section 3, the primary location is https://yourdomain.com/.well-known/security.txt. A secondary fallback at https://yourdomain.com/security.txt is also supported, but placing it in the /.well-known/ path is strongly recommended.
securitytxt.org was created by the original authors who submitted the internet-draft to the IETF. It is recognized globally by cybersecurity agencies (including CISA, NCSC, and ENISA) as the official specification repository for vulnerability disclosure standards.
Generates syntactically valid security.txt files conforming to the official IETF RFC 9116 and securitytxt.org specifications.
Gives ethical hackers and security researchers a clear contact channel instead of posting zero-days publicly.
Define public encryption keys so bug bounty reporters can safely encrypt sensitive exploit reproductions.
Automatically sets and formats UTC expiration dates to comply with RFC 9116 freshness requirements.
Meets CISA Binding Operational Directive (BOD 20-01), NIS2 requirements, and vendor security questionnaires (SOC 2, ISO 27001).
Download a production-ready security.txt file ready to deploy immediately to /.well-known/security.txt.
Enter your target domain name to automatically pre-populate standard contact channels.
Configure mandatory contact lines (email mailto: or web submission form https://) and expiration date.
Optionally add PGP encryption keys, security policy links, or hall of fame acknowledgements (or leave them empty if you don't have them).
Copy or download the generated security.txt file and upload it to your web server at /.well-known/security.txt.
A security.txt file is a standard text file placed at /.well-known/security.txt that informs security researchers and automated scanners on how to securely report vulnerabilities found on your website.
Under RFC 9116 Section 3, the primary location is https://yourdomain.com/.well-known/security.txt. A secondary fallback at https://yourdomain.com/security.txt is also accepted.
The RFC 9116 standard requires an expiration date so that outdated contact addresses and security policies are not used indefinitely. Stale files are flagged by automated scanners.
Yes. Search engines and security auditing algorithms check /.well-known/security.txt as a positive signal of proactive security hygiene, compliance, and active domain maintenance.
Your web server must serve the security.txt file with a Content-Type of text/plain (with charset UTF-8) and an HTTP 200 OK status code.
WebKernelAI tools use high-fidelity crawlers and security engines to provide actionable data for developers, SEOs, and website owners.