Security.txt: The Simple File That Makes Your Site Easier to Report Vulnerabilities On

The concept is simple: just as robots.txt tells search engines how to crawl your site, security.txt tells researchers how to report security issues. Without it, a well-intentioned researcher who discovers a flaw on your site has no clear way to reach the right person — and may simply give up, post the finding publicly, or move on.

Here is a minimal example of what a security.txt file looks like:

That is it. Two lines, and your site is already more responsible-disclosure-friendly than the majority of the internet.

Why You Need It (Responsible Disclosure)

Most websites have no dedicated security contact. When someone discovers a vulnerability, they face a frustrating maze: generic contact forms, info@ email addresses, support chatbots that cannot route security reports. The result is predictable — the issue goes unreported.

A security.txt file solves this by providing:

• A clear point of contact — researchers know exactly who to email
• A defined policy — you can link to your vulnerability disclosure program (VDP)
• Legal clarity — researchers can see whether you welcome reports
• Faster response times — reports reach the right person instead of bouncing through departments

Google, Facebook, GitHub, and the UK government all use security.txt. The US Cybersecurity and Infrastructure Security Agency (CISA) actively recommends it for all organizations.

Real-world impact

In 2023, a researcher discovered an open admin panel on a regional bank's website. The bank had no security contact listed anywhere. The researcher spent three weeks trying to reach someone through customer support before giving up. A security.txt file with a direct email would have resolved the issue in hours.

The security.txt Standard (RFC 9116)

RFC 9116 defines several fields. Here is the full specification:

Important rules:

1. 1The Contact field is mandatory and must appear at least once
2. 2The Expires field is mandatory — set it no more than one year in the future
3. 3The file should be digitally signed with PGP (recommended but not required)
4. 4Comments start with #

How to Create Your security.txt

Here is a complete, production-ready security.txt file:

Step by step

1. 1Create the file — Open a text editor and create a file named security.txt
2. 2Add the Contact field — Use a dedicated security email, not your personal inbox
3. 3Set the Expires date — Pick a date within the next 12 months
4. 4Add optional fields — Policy, Encryption, and Acknowledgments are highly recommended
5. 5Sign it with PGP (optional but recommended):

Setting up a dedicated email

Do not use info@ or support@. Create a dedicated alias like security@yourcompany.com that routes to your technical team. If you use a ticketing system, consider using a URL contact that creates a ticket directly.

Where to Put It

The file must be accessible at one of these two locations:

• Preferred: https://yoursite.com/.well-known/security.txt
• Legacy: https://yoursite.com/security.txt

RFC 9116 specifies the .well-known path as the primary location. The root path is supported for backward compatibility.

Nginx

Apache

Next.js / Vercel

Place the file at public/.well-known/security.txt in your project. It will be served automatically.

Cloudflare Pages

Place the file at public/.well-known/security.txt. Alternatively, use a Cloudflare Worker:

Common Mistakes

1. Forgetting the Expires field

Without Expires, automated tools and researchers cannot know if the file is still maintained. Always include it, and set a calendar reminder to update it.

2. Using an unmonitored email

If reports go to an inbox nobody checks, you have the illusion of security without the benefit. Route security emails to a monitored queue.

3. Placing it only at the root

Some scanners only check /.well-known/security.txt. Put the file there first, and optionally add a copy at the root for maximum compatibility.

4. Setting Expires too far in the future

RFC 9116 recommends a maximum of one year. Anything beyond that suggests the file is unmaintained.

5. Not updating after team changes

When your security contact leaves the company, update the file immediately. Stale contacts erode trust.

6. Blocking it with robots.txt

Ensure your robots.txt does not disallow access to /.well-known/. Some default configurations accidentally block this path.

Test Your Implementation

After deploying your security.txt, verify it works:

You should see a 200 OK response with Content-Type: text/plain.

Online validators:

• securitytxt.org — validates format and offers a generator
• internet.nl — comprehensive website security test including security.txt

Checklist before going live

• [ ] Contact field points to a monitored email or URL
• [ ] Expires is set within 12 months
• [ ] File is accessible at /.well-known/security.txt
• [ ] Content-Type header is text/plain
• [ ] File is not blocked by robots.txt or WAF rules
• [ ] (Optional) File is PGP-signed

How ZeriFlow Checks It

When you run a security scan on zeriflow.com, one of the checks specifically looks for your security.txt file. The scanner verifies:

• Whether the file exists at /.well-known/security.txt
• Whether it contains a valid Contact field
• Whether it contains a valid Expires field that has not passed
• Whether the file is served with the correct content type

If your security.txt is missing or misconfigured, your security score takes a hit in the Best Practices category. The fix takes under 10 minutes and earns you easy points.

Run a free scan at zeriflow.com to see where your site stands — including your security.txt status.

Further Reading

• RFC 6797 — HTTP Strict Transport Security (HSTS)
• OWASP Top 10 Web Application Security Risks

<!-- zf-internal-links -->