Outputs according to RFC 9116, ready to deploy at /.well-known/security.txt.
Declare the canonical URL for your security.txt to prevent spoofing on other paths
Generate RFC 9116-compliant security.txt files online, providing security researchers with a formal vulnerability reporting channel. Real-time preview, one-click copy, deploy directly to /.well-known/security.txt to take effect.
security.txt is a web security standard defined by the IETF in RFC 9116, designed to provide websites with a standardized way to publish security contact information. When security researchers (white hat hackers) discover security vulnerabilities on your website, they need to know who to contact, how to encrypt their reports, and what disclosure policy to follow. Without security.txt, researchers may not find the right person, and vulnerabilities could be publicly disclosed or even maliciously exploited. Google, GitHub, Facebook/Meta, the UK Government, US CISA, and the governments of France, Italy, the Netherlands, and Australia have all adopted this standard.
Per RFC 9116 standards, security.txt must be placed at the /.well-known/security.txt path (i.e., in the .well-known folder at your website's root). You can also place a copy at /security.txt in the root directory as a fallback. It must be accessible via HTTPS, and the Content-Type must be text/plain. Do not place it in other paths, as automated security scanning tools will not recognize it.
Three formats are supported: email addresses must use the mailto: prefix (e.g., mailto:security@example.com), web URLs must use the https:// prefix (e.g., https://example.com/security-report), and phone numbers must use the tel: prefix (e.g., tel:+1-201-555-0123). You can enter multiple contacts, one per line—security researchers can choose the most convenient channel to reach you. It is recommended to provide at least one email address and one web form link.
Expires is a mandatory field (Contact is also mandatory; all others are optional). Expires indicates the expiration time of the security.txt content and must use ISO 8601 format UTC time, e.g., 2027-12-31T23:59:59Z (Z indicates UTC timezone). It is recommended to set expiration for 6-12 months after creation to remind yourself to regularly update security contact information. After expiration, automated tools will consider the file's information potentially invalid.
The Encryption field points to the location of your PGP public key. Security researchers can use this public key to encrypt vulnerability reports before sending them, preventing vulnerability details from being intercepted during email transmission. This is not a mandatory field, but it is strongly recommended—because vulnerability information is highly sensitive, plaintext emails can be eavesdropped on by ISPs, mail server administrators, or attackers. You can place your PGP public key at /.well-known/pgp-key.txt and enter that URL in the Encryption field.
The Acknowledgments field points to a public acknowledgments page (also called a Security Hall of Fame), listing the names or IDs of researchers who have previously reported security vulnerabilities to you. This is public recognition of security researchers' work and an effective way to attract more white hat researchers to help you find vulnerabilities. Many security researchers prioritize testing websites with public acknowledgment mechanisms, as it means their contributions will be recognized.
The Policy field should link to your Vulnerability Disclosure Policy (VDP) page. This page should clearly state: which testing activities are permitted (and which are prohibited, e.g., no DDoS, no accessing user data), response time commitments for vulnerability reports, whether you offer bounties, and your legal commitments to legitimate security research (e.g., not prosecuting good-faith researchers). A clear Policy provides security researchers with legal peace of mind, reassuring them that they can safely report issues to you.
The Canonical field declares the canonical URL of the security.txt file itself. A website may have security.txt accessible at multiple domains or paths (e.g., example.com and www.example.com); the Canonical field tells researchers which URL is the official, trusted version. This prevents attackers from placing a forged security.txt on some path to trick researchers into sending vulnerability reports to the attacker. It is recommended to fill in your official domain URL, such as https://example.com/.well-known/security.txt.
Preferred-Languages tells security researchers which languages your security team can handle for reports, expressed as comma-separated language codes (e.g., en, zh-CN, ja). This generator automatically sets this field based on the page language you are currently using. This is important because security research is global—researchers may be in any country, and stating supported languages upfront prevents communication failures due to language barriers.
Yes, Hiring is one of the optional fields defined in the RFC 9116 standard. This field points to your security team's recruitment page. Security researchers themselves are excellent security talent candidates—their ability to find vulnerabilities on your website demonstrates strong security capabilities. Placing a recruitment link in security.txt is a highly targeted way to recruit security talent. Many well-known companies (including Google) include recruitment links in their security.txt.
This is the most common concern among website operators. There are several strategies to reduce spam: first, instead of posting email addresses directly, post a URL to a security report web form (https:// prefix), where you can add CAPTCHA to filter bots; second, use a dedicated security email alias (e.g., security@) and configure strong spam filtering; third, provide PGP public key encryption—automated spam senders do not use PGP encryption; fourth, clearly state in your Policy that you only accept reports related to security vulnerabilities. In practice, most websites that have implemented security.txt report negligible increases in spam, but significant increases in vulnerability reports.
RFC 9116 recommends (but does not require) using OpenPGP cleartext signatures to digitally sign security.txt, so researchers can verify that the file was indeed officially published by the website and has not been tampered with by attackers. The method is to use GPG to clearsign the file: gpg --clearsign -o security.txt.sig security.txt, then use the signed content (starting with -----BEGIN PGP SIGNED MESSAGE-----) as the final security.txt content. However, this is an advanced operation—most websites can function normally without signing.
Core configuration requirements: ensure the /.well-known/security.txt path is accessible, Content-Type returns text/plain, HTTPS must be used, and do not redirect this path (especially do not redirect to other domains). Nginx can use exact location matching: location = /.well-known/security.txt { default_type text/plain; alias /path/to/security.txt; }; Apache should ensure .htaccess does not block access to the .well-known directory; Caddy can use handle_path to specify directly.
It is highly recommended. Regardless of website size, as long as you have user data or provide services on the internet, security vulnerabilities may exist. The deployment cost of security.txt is extremely low—generating with this tool takes only 2 minutes and requires placing one file. Large companies like Google and GitHub use it, and individual developers and open source projects can use it too. It is an extremely cost-effective security practice: almost zero cost, yet it gives good-faith researchers who find vulnerabilities a channel to tell you about problems, rather than leaving silently or disclosing publicly.
Both are standard text files placed under /.well-known/ (or the root directory), but their purposes are completely different: robots.txt is for search engine crawlers, telling them which paths not to crawl; security.txt is for security researchers, telling them how to contact you if they find vulnerabilities. One targets search engines, the other targets security researchers—they complement each other without conflict and can be deployed simultaneously.
security.txt is a web security best practice formally standardized by the IETF (Internet Engineering Task Force) in RFC 9116, designed to provide websites with a unified, standard way to publish security contact information. Simply put, it is a text file placed at a fixed path on a website, telling security researchers (white hat hackers): "If you find security vulnerabilities on my website, here is how to contact us, here is our encryption public key, here is our disclosure policy, and we welcome your reports."
Before the security.txt standard existed, website security contact information was haphazard. Some websites had no security contact information at all, some buried it on some obscure page, some only listed an unattended info@ email, and some required painstaking searching on LinkedIn to find the security team. This caused a serious problem: when good-faith security researchers discovered vulnerabilities, they often could not find the correct channel to report them. The result was—many vulnerabilities were silently shelved, left unpatched, until discovered and exploited by malicious hackers. security.txt was born to solve this "last mile" problem.
The concept of security.txt was first proposed by security researchers EdOverflow and Yakov Shafranovich in 2017 and quickly gained widespread industry support. In April 2022, security.txt was formally approved by the IETF as RFC 9116, becoming an internationally recognized web security standard. Today, major technology companies such as Google, GitHub, Meta (Facebook), LinkedIn, and Cloudflare, as well as government agencies including the UK Government, US CISA (Cybersecurity and Infrastructure Security Agency), French Government, Italian Government, Dutch Government, and Australian Cyber Security Centre, have deployed security.txt on their official websites and publicly recommend that other organizations adopt it.
The core design of the security.txt file is very simple—it is a plain text file consisting of lines in the format "field-name: value", similar to HTTP header format. The standard defines two mandatory fields: Contact (security contact information, which can be multiple) and Expires (file expiration time); as well as several optional fields: Encryption (PGP encryption public key URL), Acknowledgments (acknowledgments page URL), Policy (vulnerability disclosure policy URL), Hiring (security jobs URL), Canonical (canonical file URL), Preferred-Languages (supported report languages), and CSAF (Common Security Advisory Framework provider metadata URL). This simple format makes it easy for both humans and machines to parse.
Why is deploying security.txt so important? First, it lowers the barrier to vulnerability reporting. Security researchers do not need to spend significant time finding contact information—they can find the correct reporting channel with one click. Second, it demonstrates an organization's proactive attitude toward security—a website with security.txt is essentially saying "We take security seriously and welcome responsible reports." Third, it reduces the risk of vulnerabilities being publicly disclosed or exploited: with a formal channel, researchers will not choose to publicly disclose vulnerabilities directly on Twitter or GitHub because they cannot reach anyone. Fourth, in many industry regulatory requirements (e.g., finance, healthcare, government), establishing a vulnerability disclosure channel has become a compliance requirement.
There are several key details to note when deploying security.txt. First, the path must be correct: the standard path is /.well-known/security.txt, and you can also place a copy at /security.txt in the root directory as a fallback. The .well-known directory here is a standard "well-known resources" directory defined by RFC 8615, where other standard files such as robots.txt are also placed in related locations. Second, it must be served over HTTPS—plaintext HTTP is considered insecure. Third, Content-Type must be text/plain, not text/html or other types. Fourth, do not perform cross-domain redirects for security.txt—if https://example.com/.well-known/security.txt redirects to https://other-domain.com/security.txt, researchers and automated tools will consider this suspicious. Fifth, remember to set the Expires field and update it regularly; an expired security.txt will be considered to have unreliable information.
The Contact field is the most important field in security.txt and the only truly essential field (Expires is also mandatory but is just a timestamp). Contact supports three URI formats: mailto: for email addresses, https:// for web links (e.g., security report form pages), and tel: for phone numbers. It is strongly recommended to provide at least one mailto email and one https form link—forms prevent bot spam, while email is more convenient for researchers to directly send encrypted reports. Multiple contacts can be listed on multiple lines, for example providing both the security team email, security lead email, and third-party vulnerability platform links simultaneously.
While the Encryption field is optional, it is very important in practice. When security researchers discover a critical vulnerability (such as user data leakage or remote code execution), they absolutely do not want to send vulnerability details in plaintext email—because email passes through multiple servers during transmission, any hop could be eavesdropped on. PGP (Pretty Good Privacy) public key encryption is the industry standard for secure communication. You only need to generate a PGP key pair, place the public key on your website (e.g., at /.well-known/pgp-key.txt), and enter that URL in the Encryption field. Researchers encrypt report content with your public key, and only those holding the corresponding private key can decrypt and read it.
The Policy field links to your Vulnerability Disclosure Policy (VDP) page, which is key to building researcher trust. A good VDP should clearly state: testing scope (which systems are in scope and which are out of scope), permitted testing methods (e.g., SQL injection/XSS testing allowed but DDoS/social engineering/accessing real user data prohibited), committed response times (e.g., "We will acknowledge receipt of reports within 3 business days"), whether bounties are offered, and legal safe harbor commitments (explicitly stating no prosecution of good-faith researchers who follow the rules). There are many VDP templates available internationally for reference, and US CISA also provides an open source VDP template.
Beyond security contact itself, security.txt has several "surprise" fields. The Acknowledgments field builds a Security Hall of Fame—publicly thanking researchers who help you find vulnerabilities, which recognizes their work and also serves as community building. The Hiring field is a very clever design: people who can find vulnerabilities on your website are inherently excellent security talent, and placing a recruitment link in security.txt is the most precise channel for recruiting security talent. Many companies have hired excellent security engineers through security.txt. The Canonical field is a security consideration—preventing attackers from forging your security.txt on other domains.
Regarding the common concern about spam, in practice most organizations that have deployed security.txt report negligible increases in spam. This is because: first, spammers typically do not obtain email addresses by crawling security.txt; second, https:// form links can be used instead of directly placing mailto emails, and adding CAPTCHA to forms can completely block bots; third, dedicated security emails (e.g., security@) usually have strict spam filtering configured. In contrast, the cost of missing critical vulnerability reports due to lack of a security contact channel far outweighs the potential increase in small amounts of spam.
This generator is built in strict compliance with the RFC 9116 standard, and all output formats are normalized: the Contact field automatically recognizes prefixes, the Expires field uses standard ISO 8601 UTC time format, and Preferred-Languages is automatically set based on the language you are using. The generated content can be directly copied and deployed to the /.well-known/security.txt path without any modifications. Additionally, all configuration is done locally in your browser and never sent to any server—your security contact information always remains on your device. Deploying security.txt takes only 5 minutes, but the security communication channel it establishes could help you avoid a serious security incident in the future.
Below are all fields defined by the security.txt standard and their requirements:
| Field Name | Required/Optional | Multiple Allowed? | Value Format | Description |
|---|---|---|---|---|
| Contact | ✅ Required | ✅ Multiple lines allowed | mailto:/https:/tel: URI | Security contact information, supports email, web URL, and phone formats |
| Expires | ✅ Required | ❌ Exactly one | ISO 8601 UTC time | File content expiration time; after expiration, information is considered potentially invalid |
| Encryption | ⬜ Optional | ✅ Multiple lines allowed | https:// URI | PGP public key location URL for encrypting sensitive vulnerability reports |
| Acknowledgments | ⬜ Optional | ✅ Multiple lines allowed | https:// URI | Security Hall of Fame/acknowledgments page URL, publicly thanks vulnerability reporters |
| Policy | ⬜ Optional | ✅ Multiple lines allowed | https:// URI | Vulnerability Disclosure Policy (VDP) page URL, describes reporting rules and scope |
| Hiring | ⬜ Optional | ✅ Multiple lines allowed | https:// URI | Security team recruitment page URL, recruits talent from security researchers |
| Canonical | ⬜ Optional | ✅ Multiple lines allowed | https:// URI | Canonical URL of the security.txt file itself, prevents forgery |
| Preferred-Languages | ⬜ Optional | ❌ Exactly one | Language codes (comma-separated) | Languages supported by the security team, e.g., en, zh-CN, ja |
| CSAF | ⬜ Optional | ✅ Multiple lines allowed | https:// URI | Common Security Advisory Framework provider metadata URL |
After generating security.txt content, configure the correct access path and Content-Type on your server:
| Web Server | Configuration Key Points | Notes |
|---|---|---|
| Nginx | location = /.well-known/security.txt { default_type text/plain; alias /var/www/.well-known/security.txt; add_header Cache-Control "public, max-age=3600"; } | Use exact matching (=), specify default_type as text/plain to prevent Nginx from treating txt files as binary |
| Apache | Ensure the .well-known directory is not blocked by .htaccess Deny rules; simply place the file in the .well-known folder under the website root directory | Apache returns text/plain for .txt files by default, but confirm that mod_rewrite rules do not rewrite this path |
| Caddy | handle_path /.well-known/security.txt { file_server { root /var/www } } | Caddy defaults to HTTPS and correctly handles txt file MIME types; simplest configuration |
| Cloudflare Pages/Vercel/Netlify | Place security.txt at public/.well-known/security.txt; after deployment, static serving will allow correct access | Static hosting platforms usually handle the correct Content-Type automatically; confirm that platforms do not ignore the .well-known directory when it starts with a dot |
| CDN/Reverse Proxy | Ensure CDNs or WAFs do not block or cache security.txt for too long; recommended Cache-Control setting is max-age=3600 (1 hour) | Remember to purge CDN cache after updating security.txt, otherwise researchers may see old versions |
All configuration operations in this generator run entirely locally in your browser. None of the information you enter—security contact emails, PGP key URLs, job links, or any other data—is sent to any server, nor is it collected or stored. All input content is immediately cleared when the page is refreshed or closed. The generated security.txt file content exists only in your clipboard and on servers you deploy to; GeekFormat retains no copies.
There are three common causes: first, the file is not placed in the correct location—confirm the path is the security.txt file inside the .well-known folder at the website root (note that .well-known is a hidden directory starting with a dot); second, web server configuration blocks access to directories starting with a dot (Apache .htaccess or Nginx deny rules may block dotfile directories); third, Nginx/Apache rewrite rules (such as frontend routing history mode) are forwarding requests to index.html. Solution: check the file path and explicitly add a location rule for /.well-known/security.txt in the server configuration.
Many single-page applications (SPAs) or websites with authentication redirect all unmatched paths to the homepage or login page. This prevents automated tools from finding security.txt. Solution: add an exception for the /.well-known/security.txt path in the server configuration so that this path returns file content directly, bypassing SPA routing or authentication middleware processing. This is the most common pitfall when deploying security.txt.
This occurs because the server returns an incorrect Content-Type, possibly set to application/octet-stream or another binary type instead of text/plain. Solution: explicitly set Content-Type to text/plain; charset=utf-8 for security.txt in the web server configuration. Nginx requires default_type text/plain or add_header Content-Type text/plain; Apache usually handles this automatically, but if problems occur, you can use the AddType directive to force specification.
Contact field values must include URI prefixes: email addresses must start with mailto: (e.g., mailto:security@example.com, not just security@example.com), web URLs must start with https:// (not just example.com/security), and phone numbers must start with tel:. This is explicitly required by RFC 9116 standards—because the Contact field supports multiple contact methods, lacking prefixes makes it impossible for parsers to determine the type.
Expires must use ISO 8601 format UTC time in the format YYYY-MM-DDTHH:MM:SSZ, with a Z at the end indicating UTC timezone (do not write local timezone offsets such as +08:00). Correct example: 2027-12-31T23:59:59Z. Do not use other formats such as 2027/12/31, Dec 31 2027, or 2027-12-31 23:59:59—these are non-compliant.
Check the following points: first, ensure access uses HTTPS (HTTP access does not count—RFC requires HTTPS); second, ensure correct access with both www and non-www domains (if your website exists in both domain versions, it is recommended to declare the primary domain in the Canonical field and place security.txt under both domains or set correct 301 redirects); third, check if CDN cache has been purged of old content; fourth, confirm the server does not return redirects (301/302) to other URLs on the security.txt path—RFC specifies that redirects may be rejected by tools.
