What is security.txt?
security.txt is a plain text file that you place on your web server to tell security researchers how to contact you about vulnerabilities they find on your site. Think of it as a "contact us" page specifically for security issues. Instead of a researcher having to guess whether they should email your support team, post on Twitter, or just give up, security.txt gives them a direct, official channel.
The format is defined in RFC 9116 (Request for Comments 9116), a standard published by the Internet Engineering Task Force (IETF). RFC 9116 specifies exactly where the file should live, what fields it can contain, and how those fields should be formatted. This standardization means security scanners, automated tools, and researchers all know where to look and what to expect. You can also visit securitytxt.org for an interactive generator and additional resources.
The file lives at a specific, predictable path on your web server: /.well-known/security.txt. The /.well-known/ directory is a reserved location on web servers used for site-wide metadata files. It is defined in RFC 8615 and is where browsers and tools look for things like Apple Pay domain verification, Let's Encrypt challenge files, and now security contact information.
Where does the name come from?
The concept was originally proposed by security researcher Edwin Foudil in 2017, drawing inspiration from robots.txt, the long-established convention for telling web crawlers which pages to skip. Just as robots.txt is a simple, universally understood file at a predictable location, security.txt follows the same philosophy for vulnerability disclosure.
Before security.txt existed, there was no agreed-upon way for researchers to find contact details. Some sites buried a security contact in their terms of service. Others expected researchers to find a general support email and hope it reached the right person. Many researchers simply gave up or, worse, disclosed vulnerabilities publicly because they had no way to report them privately.
Why Your Website Needs security.txt
Security researchers, penetration testers, and curious developers spend a lot of time poking at websites. Sometimes they find real vulnerabilities. What happens next depends entirely on whether you have made it easy for them to reach you.
Without security.txt, a researcher who finds a vulnerability in your site faces a frustrating choice. They can spend time hunting for a contact email, they can disclose the issue publicly, or they can simply walk away. None of those outcomes are good for you. Public disclosure before you have had a chance to patch means attackers can exploit the flaw before a fix is ready. A researcher walking away means the vulnerability goes unreported and unfixed indefinitely.
From a compliance perspective, some frameworks are beginning to recommend or require coordinated vulnerability disclosure programs. The US Cybersecurity and Infrastructure Security Agency (CISA) has issued guidance encouraging federal agencies and critical infrastructure operators to publish security.txt files. The UK National Cyber Security Centre (NCSC) has similarly promoted the standard. Even if your organization is not covered by these specific mandates, adopting security.txt signals maturity in your security program. If compliance is a priority for your team, see our compliance audits guide for more on generating evidence for frameworks like SOC 2, PCI DSS, and GDPR.
Perhaps most importantly, security.txt costs almost nothing to implement. It is a small text file. Adding it to your site takes minutes. The potential benefit, catching a vulnerability before an attacker does, is enormous compared to that effort.
The Required and Optional Fields
RFC 9116 defines two required fields and several optional ones. Each field appears on its own line in the format Field-Name: value. Lines beginning with # are comments and are ignored by parsers.
Contact (required)
The Contact field tells researchers where to send their vulnerability reports. You can provide an email address, a web URL (such as a bug bounty platform or a web form), or a phone number. You can include multiple Contact lines to give researchers more than one option.
Contact: mailto:security@example.com Contact: https://bugcrowd.com/example
Expires (required)
The Expires field tells researchers when the information in the file is no longer valid. After this date, they should not rely on the contact details. The date must be in ISO 8601 format, including the time and timezone offset. RFC 9116 recommends keeping this date no more than one year in the future so that stale files do not circulate indefinitely.
Expires: 2027-03-21T00:00:00.000Z
Encryption (optional)
The Encryption field points to your PGP public key. Researchers can use this key to encrypt their vulnerability reports before sending them, ensuring that only your security team can read the contents. This is especially valuable for high-severity disclosures involving sensitive details.
Encryption: https://example.com/pgp-key.txt
Acknowledgments (optional)
The Acknowledgments field links to a page where you publicly thank researchers who have reported vulnerabilities responsibly. A hall of fame page like this is a meaningful incentive for researchers to report issues to you rather than disclosing publicly.
Acknowledgments: https://example.com/security/hall-of-fame
Preferred-Languages (optional)
The Preferred-Languages field lists the language codes your security team can handle. Use standard IETF language tags such as en for English or fr for French. This helps international researchers know whether they can write in their native language.
Preferred-Languages: en, fr, de
Canonical (optional)
The Canonical field contains the full URL where the security.txt file is officially hosted. This is useful when the file might be mirrored or referenced from multiple locations. It tells parsers which copy is the authoritative one.
Canonical: https://example.com/.well-known/security.txt
Policy (optional)
The Policy field links to your vulnerability disclosure policy (VDP). A VDP outlines the rules of engagement: what is in scope, what is out of scope, your response timeline, and what researchers can and cannot do while testing. Having a published policy protects both you and the researcher.
Policy: https://example.com/security/vulnerability-disclosure-policy
Hiring (optional)
The Hiring field links to security job openings at your organization. It is a small but friendly gesture toward the security community: if a researcher is interested in doing this kind of work full time, you are pointing them toward an opportunity.
Hiring: https://example.com/careers/security
Complete security.txt Example
Here is a complete security.txt file that uses all of the fields described above. In practice, you only need Contact and Expires to be compliant with RFC 9116. Everything else is optional but recommended.
# Security contact information for Example Corp # See https://securitytxt.org for more information Contact: mailto:security@example.com Contact: https://bugcrowd.com/example Expires: 2027-03-21T00:00:00.000Z Encryption: https://example.com/pgp-key.txt Acknowledgments: https://example.com/security/hall-of-fame Preferred-Languages: en, fr Canonical: https://example.com/.well-known/security.txt Policy: https://example.com/security/vulnerability-disclosure-policy Hiring: https://example.com/careers/security
How to Create and Deploy security.txt
Deployment is straightforward for most web servers. The key requirement is that the file must be accessible at /.well-known/security.txt over HTTPS. The steps below cover the most common server configurations.
Nginx
Create the /.well-known/ directory in your web root and place the file there. Nginx serves static files from the root directory by default, so no additional configuration is usually needed. If you have strict location rules, add an explicit block.
# Create the directory and file
mkdir -p /var/www/html/.well-known
nano /var/www/html/.well-known/security.txt
# Optional: explicit Nginx location block (nginx.conf or site config)
location /.well-known/security.txt {
default_type text/plain;
alias /var/www/html/.well-known/security.txt;
}Apache
On Apache, create the directory and file in your document root. Apache serves the file automatically. If you have a .htaccess file that blocks access to dot-directories, you may need to explicitly allow the /.well-known/ path.
# Create the directory and file
mkdir -p /var/www/html/.well-known
nano /var/www/html/.well-known/security.txt
# If needed, add to .htaccess to allow access to .well-known
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^.well-known/ - [L]
</IfModule>Express / Node.js
In an Express application, you can either serve the file as a static asset or define a dedicated route. Using a static directory is simpler and requires no ongoing maintenance when you update the file.
// Option 1: Serve the .well-known directory as static files
// Place security.txt at: public/.well-known/security.txt
app.use('/.well-known', express.static(path.join(__dirname, 'public/.well-known')));
// Option 2: Inline route handler
app.get('/.well-known/security.txt', (req, res) => {
res.setHeader('Content-Type', 'text/plain');
res.send(`Contact: mailto:security@example.com
Expires: 2027-03-21T00:00:00.000Z
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security/vulnerability-disclosure-policy
Preferred-Languages: en`);
});Vercel
For projects deployed on Vercel, place the file in the public directory of your project. Vercel serves everything in the public directory as static files at the corresponding URL path.
# Directory structure
your-project/
public/
.well-known/
security.txt <-- place your security.txt here
# The file will be served at:
# https://yourdomain.com/.well-known/security.txtNote for React apps: If you are using Create React App or Vite, the public directory is already set up to serve static files. Just drop the .well-known/security.txt file in there and it will be deployed automatically.
Netlify
Netlify works similarly to Vercel. Place the file in your publish directory (typically public, dist, or build depending on your framework). The file will be served as a static asset.
# For a static site with Netlify
# Place file at: public/.well-known/security.txt
# If you need custom headers for the file, add to netlify.toml
[[headers]]
for = "/.well-known/security.txt"
[headers.values]
Content-Type = "text/plain"Best Practices
A security.txt file that is outdated or hard to trust is worse than no file at all. Researchers who find an expired file or dead contact link may conclude your security program is not active and lose confidence in reporting to you. Follow these practices to keep your security.txt effective.
Keep the Expires date no more than one year out
RFC 9116 recommends this as a maximum. It forces a regular review cycle and ensures stale files do not linger. Set a calendar reminder to refresh the file before it expires.
Use HTTPS for all URLs in the file
Every URL referenced in your security.txt should use https://. This includes the Contact URL, Canonical, Policy, Acknowledgments, Encryption key, and Hiring links. HTTP URLs undermine trust and risk man-in-the-middle tampering.
Sign the file with PGP if possible
RFC 9116 allows you to sign your security.txt file using OpenPGP. A signed file gives researchers confidence that the file has not been tampered with, which is important because the file contains contact details they will trust with sensitive vulnerability information.
Monitor the contact email or inbox actively
If researchers send reports and hear nothing back, they will assume no one is watching and may disclose publicly. Make sure the address listed in Contact reaches someone who checks it regularly and responds promptly.
Test that the file is publicly accessible
After deploying, verify the file is reachable at https://yourdomain.com/.well-known/security.txt. Check that it returns a 200 OK status and the correct content type. Some server configurations block access to dot-directories, which would make the file invisible.
Include a vulnerability disclosure policy
The Policy field links researchers to your rules of engagement. Without a published policy, researchers do not know whether they could face legal action for testing your systems in good faith. A clear policy reduces this ambiguity and encourages responsible reporting.
Common Mistakes to Avoid
Most security.txt problems come down to one of a handful of recurring errors. Knowing what to watch for will save you from publishing a file that researchers cannot use or that makes your security program look neglected.
Forgetting to update the Expires field
An expired security.txt is almost as bad as none at all. Parsers and tools may reject expired files entirely. Researchers who see an expired file may question whether anyone is still actively managing your security program. Set a recurring reminder to refresh the file at least once a year.
Using HTTP instead of HTTPS for URLs
Any URL in your security.txt that uses plain HTTP is a red flag. It opens the door to tampering during transmission and sends a poor signal to security-conscious researchers. All references must use https://.
Not monitoring the contact email
Publishing a contact address and then ignoring it is the most damaging mistake. Researchers who receive no response will lose confidence and may publish their findings publicly. Treat the security contact inbox like a support queue with a defined response SLA.
Placing the file in the wrong directory
The canonical location is /.well-known/security.txt. Placing the file at /security.txt (the root) was acceptable in earlier drafts of the specification but is not the standard location per RFC 9116. Automated tools and scanners look specifically at the /.well-known/ path first.
Missing the Contact field
Contact is the only field that is truly essential. Without it, the file is meaningless. A security.txt file with only an Expires field tells researchers nothing useful. Always include at least one Contact entry.
How SiteSecurityScore Checks security.txt
When you scan a site with SiteSecurityScore, the scanner requests /.well-known/security.txt and evaluates what it finds. Here is what the scanner checks:
The results appear in your scan report alongside your other security headers, giving you a clear picture of where security.txt fits into your overall security posture. For a full walkthrough of what a scan covers, see our security audit guide. Sites that are missing security.txt or have common issues will receive specific, actionable recommendations.
Scan your site now
Find out whether your site has a valid security.txt file and see how your overall security headers score.
Never miss an expired security.txt again
Your security.txt file can expire, contacts can change, and policies can go stale without anyone noticing. Automated monitoring catches these changes the day they happen.
Already have an account?