What is security.txt and Why Your Site Needs One
TL;DR: Security.txt is a standardized text file (RFC 9116) that tells security researchers how to report vulnerabilities in your website. Place it at /.well-known/security.txt, include at minimum a Contact field and Expires date, and you'll make it easy for good-faith researchers to help secure your site instead of giving up or going public with their findings.
Imagine a security researcher finds a vulnerability in your website. They want to report it responsibly, but your site has no bug bounty program, no security email listed, and your contact page goes to customer support. What happens? Often, they give up, and that vulnerability stays unfixed. Sometimes, they go public, and you find out about the flaw the same time everyone else does.
Security.txt solves this problem.
What is security.txt? {#definition}
Security.txt is a proposed standard (RFC 9116) that defines a simple text file websites can use to communicate security contact information and vulnerability disclosure policies. Located at /.well-known/security.txt, it provides a consistent, machine-readable way for security researchers to find the right people to contact when they discover vulnerabilities. Think of it as the security equivalent of robots.txt, a convention that makes the internet work better for everyone.
Why security.txt Matters for Indie Hackers
You might think vulnerability disclosure is only for big companies with bug bounty programs. It matters just as much for your indie project, and here's why.
Security researchers scan the internet constantly, and they find vulnerabilities everywhere. Your side project might have a SQL injection that a researcher stumbles upon during routine scanning. Without security.txt, they have no easy way to tell you about it, and that vulnerability remains unfixed.
Security.txt provides free protection. Bug bounty programs cost money, but security.txt costs nothing except a few minutes of setup time. Even without paying bounties, many researchers will report issues just to help out, especially for smaller projects and indie developers.
Having a security.txt file demonstrates security awareness. It signals to customers, investors, and partners that you take security seriously. It's a small detail that makes a professional impression and shows you've thought about security beyond just the obvious measures.
When researchers can't reach you privately, some will tweet about the vulnerability or post it publicly. A clear reporting channel keeps issues confidential until you fix them, preventing the PR nightmare of public disclosure.
Security.txt is also becoming expected. Major companies like Google, Facebook, GitHub, and Cloudflare all have security.txt files. As the standard spreads, not having one starts to look negligent.
How to Create a security.txt File
Creating the File
Create a plain text file with the required and recommended fields. Here's a minimal example:
Contact: mailto:[email protected]
Expires: 2027-01-01T00:00:00.000Z
And here's a more complete example:
# Our security contact information
Contact: mailto:[email protected]
Contact: https://yourdomain.com/security/report
# Our vulnerability disclosure policy
Policy: https://yourdomain.com/security/policy
# When this file expires and should be refreshed
Expires: 2027-01-01T00:00:00.000Z
# Preferred languages for reports
Preferred-Languages: en
# Our security acknowledgments page
Acknowledgments: https://yourdomain.com/security/thanks
# How to encrypt sensitive reports
Encryption: https://yourdomain.com/.well-known/pgp-key.txt
# Our hiring page for security professionals
Hiring: https://yourdomain.com/careers
Understanding the Fields
Two fields are required. The Contact field specifies how researchers should reach you and can be an email address (with mailto: prefix), a URL to a reporting form, or a phone number. Include at least one contact method. The Expires field indicates when this security.txt should be considered stale and must be refreshed. Use ISO 8601 format and set this to force yourself to review and update periodically.
Several recommended fields can improve your security.txt. The Policy field contains a URL to your full vulnerability disclosure policy. Preferred-Languages indicates which languages you can handle reports in. Acknowledgments links to a page thanking researchers who've helped. Encryption provides a URL to your PGP key for encrypted reports. Hiring links to security job postings. Canonical specifies the definitive URL for your security.txt to help prevent spoofing.
Placing the File Correctly
The file must be located at one of two paths. The preferred location per RFC 9116 is https://yourdomain.com/.well-known/security.txt. The legacy location, which is still supported, is https://yourdomain.com/security.txt. If you use both locations, the files must be identical, and the .well-known location takes precedence.
Signing the File
For maximum trust, you can sign your security.txt with PGP:
gpg --clearsign security.txt
This produces a signed version that researchers can verify came from you:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Contact: mailto:[email protected]
Expires: 2027-01-01T00:00:00.000Z
Canonical: https://yourdomain.com/.well-known/security.txt
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEE...
-----END PGP SIGNATURE-----
Testing Your Implementation
After deploying, verify that the file is accessible at the correct URL, the Content-Type header is text/plain, HTTPS is working correctly, and all linked URLs (Policy, Acknowledgments, etc.) are accessible. Several online validators can check your security.txt format, including securitytxt.org, Hardenize, and Security Headers.
security.txt Best Practices
Monitor your security inbox because having a contact email is useless if no one reads it. Set up alerts and check the inbox regularly, or forward it to an email address you actually monitor.
Respond promptly to reports. Acknowledge them within 24-48 hours, even if you need more time to investigate. Researchers who feel ignored may decide to go public with their findings.
Set realistic expiration dates. One year is typical. Too short creates maintenance burden as you're constantly updating the file; too long means potentially outdated information that could mislead researchers.
Create a simple disclosure policy, even if it's just a basic page explaining your process. Researchers want to know what to expect when they submit a report. Will you respond? What's a typical timeline? Will you give credit?
Be gracious and thank researchers even for false positives or low-severity issues. Word spreads in the security community about who's good to work with, and a positive reputation attracts more helpful reports.
Keep your security.txt updated. When you change security contacts or processes, update the file immediately. An outdated contact that bounces frustrates researchers and may cause them to give up.
Common security.txt Mistakes to Avoid
Letting the file expire is worse than not having one at all because it signals abandonment. An expired security.txt suggests the file was set up and then forgotten, making researchers wonder if anyone will read their report. Set calendar reminders to update before expiration.
Using unmonitored email addresses defeats the purpose. If [email protected] goes to a mailbox no one checks, you won't receive reports, and researchers will wonder why you're not responding. Use an alias that reaches actual humans who will act on reports.
Making your disclosure policy too complex creates friction. Researchers don't want to read a 20-page legal document before they can tell you about a vulnerability. Keep your policy simple, clear, and focused on the essentials.
Not responding to reports, even with a simple acknowledgment, frustrates researchers and damages your reputation. Even a quick "thanks, we're looking into it" is infinitely better than silence.
Requiring NDAs before disclosure is a non-starter for most researchers. Asking people to sign legal agreements before they can even report a problem creates friction that most researchers won't bother with. They'll simply walk away, and you'll never know about the vulnerability.
Hosting security.txt on HTTP only undermines the entire point. Your security contact file served insecurely over an unencrypted connection? Researchers will rightfully distrust any information in it. Always serve security.txt over HTTPS.
What to Do When You Receive a Report
When a report comes in, acknowledge it immediately. Reply within 24-48 hours to confirm receipt:
Thank you for reporting this to us. We've received your report
and our team is investigating. We'll update you within [timeframe].
Then triage and verify the report by assessing whether it's a valid vulnerability, determining the severity and potential impact, and attempting to reproduce the issue.
Communicate your timeline to the researcher. Let them know when you expect to have a fix and how you'll handle disclosure:
We've confirmed this issue and are working on a fix. We expect
to deploy a fix within 2 weeks. We'll let you know when it's
resolved and coordinate on disclosure timing.
Fix the issue with appropriate priority. Critical issues warrant immediate attention; lower-severity issues can be scheduled appropriately based on your development workflow.
After fixing, thank the researcher properly. Consider adding them to your Acknowledgments page if they want public recognition. Some researchers appreciate reference letters, and even without a formal bounty program, a small thank-you gift or swag can build goodwill.
Coordinate with the researcher on disclosure. Discuss whether to write a full disclosure blog post, whether to assign a CVE for significant issues, or whether to simply fix the issue quietly with no announcement.
How SecurityBot Helps with security.txt
SecurityBot monitors your security.txt file to ensure it stays current and accessible. You get existence monitoring that confirms your security.txt is in place, expiration tracking that alerts you before your file expires, change detection that notifies you if the file is modified unexpectedly, and accessibility checks that ensure the file remains reachable.
Don't let your security contact information go stale.
Start your free 14-day trial - security.txt monitoring included with all plans.
Frequently Asked Questions
Is security.txt required by any regulations?
Not currently, but it's becoming a recognized best practice. Some security frameworks and questionnaires ask about vulnerability disclosure processes, and security.txt is an easy way to demonstrate you have one.
Won't security.txt attract attackers?
Attackers don't need security.txt to find contact information, and they usually don't want to contact you anyway. Security.txt helps legitimate researchers who want to help you, not harm you. The researchers who use security.txt are trying to report problems responsibly, not exploit them.
Do I need a bug bounty program?
No. Security.txt is about communication, not payment. Many researchers report vulnerabilities without expecting bounties, especially to small companies and open source projects. The file is simply about making it easy to reach the right people.
What if I get spam or fake reports?
It happens, just like any public email address attracts some spam. Most legitimate researchers send clear, professional reports with reproduction steps. Obvious spam can be ignored. The signal-to-noise ratio is generally quite good because security researchers have strong incentives to submit quality reports.
Should I include my phone number?
Generally no. Email or a web form is preferred for security reports. Phone creates urgency expectations and timezone complications. Only include a phone number if you have 24/7 security coverage and want to receive urgent calls about critical vulnerabilities.
What about a security email vs. a web form?
Both have advantages. Email is simple and universal, and anyone can send an email. Web forms can provide structure and reduce incomplete reports by prompting researchers for specific information. Many organizations list both options and let researchers choose their preferred method.
Last updated: January 2026 | Written by Jason Gilmore, Founder of SecurityBot