Security.txt: Set Up Responsible Vulnerability Disclosure (RFC 9116)

When a security researcher discovers a vulnerability in your website, how do they report it? Without a clear process, reports get lost in support tickets, ignored by marketing email, or — worst case — the researcher discloses publicly because they couldn't find anyone to tell. Security.txt (RFC 9116) solves this by providing a standardized, machine-readable file that tells researchers exactly how to report vulnerabilities.

What Is Security.txt?

Security.txt is a plain text file placed at /.well-known/security.txt on your web server. It contains contact information, disclosure policies, and other security-related metadata following the standard defined in RFC 9116.

Why It Matters

• Faster vulnerability reports: Researchers find your security contact instantly instead of searching
• Reduced public disclosure: Clear reporting channels encourage private disclosure
• Industry standard: Adopted by Google, Facebook, GitHub, and thousands of organizations
• Compliance: Demonstrates responsible disclosure readiness for auditors
• Simple to implement: A single text file — no code changes required

Security.txt File Format

A minimal security.txt file:

# Security contact for vulnerability reports
Contact: mailto:security@example.com
Expires: 2027-02-28T00:00:00.000Z
Preferred-Languages: en

Required Fields

• Contact: How to report vulnerabilities. Can be email (mailto:), URL, or phone (tel:). Multiple Contact fields are allowed.
• Expires: When this file should be considered stale. Forces regular review of security contacts. Must be less than one year in the future.

Recommended Fields

• Encryption: PGP key URL for encrypting sensitive vulnerability reports
• Acknowledgments: URL to a page thanking security researchers
• Preferred-Languages: Languages the security team can communicate in
• Canonical: The definitive URL for this security.txt file
• Policy: URL to your vulnerability disclosure policy
• Hiring: URL to security-related job positions

Complete Example

# SecScanner Security Policy
Contact: mailto:security@example.com
Contact: https://example.com/security/report
Encryption: https://example.com/.well-known/pgp-key.asc
Acknowledgments: https://example.com/security/hall-of-fame
Policy: https://example.com/security/disclosure-policy
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
Hiring: https://example.com/careers#security
Expires: 2027-02-28T00:00:00.000Z

Where to Place Security.txt

RFC 9116 specifies the file should be at:

https://example.com/.well-known/security.txt

For backward compatibility, you can also place it at the root:

https://example.com/security.txt

If both exist, the /.well-known/ location takes precedence.

Implementation by Platform

Nginx:

# Serve security.txt from .well-known directory
location = /.well-known/security.txt {
  alias /var/www/security.txt;
  default_type text/plain;
}

Next.js (App Router):

Place the file at public/.well-known/security.txt — Next.js serves files from the public directory automatically.

Vercel / Netlify:

Place the file at public/.well-known/security.txt in your project repository.

Signing Your Security.txt

RFC 9116 recommends digitally signing your security.txt with OpenPGP to prevent tampering:

# Sign the file
gpg --clearsign security.txt

# This creates a signed version with -----BEGIN PGP SIGNED MESSAGE----- header

The signed file replaces the unsigned version. Researchers can verify the signature against your published PGP key.

Vulnerability Disclosure Policy

Your security.txt should link to a disclosure policy that covers:

• Scope — which assets and domains are covered
• Safe harbor — legal protections for good-faith researchers
• Response timeline — how quickly you'll acknowledge and fix reports
• Rewards — whether you offer bug bounties
• Exclusions — attack types that are out of scope (DoS, social engineering)

Maintaining Your Security.txt

• Set a calendar reminder before the Expires date to update the file
• Update Contact information when security team members change
• Review and update your disclosure policy annually
• Monitor the security email address for reports
• Run SecScanner regularly — the Security.txt check verifies the file exists, has valid fields, and hasn't expired

Security.txt Checklist

• Create a security.txt file with Contact and Expires fields
• Place it at /.well-known/security.txt
• Add Encryption field with a PGP key for secure reports
• Link to a vulnerability disclosure policy
• Set Expires to less than one year from now
• Optionally sign the file with PGP
• Test accessibility from a browser
• Run a SecScanner scan to verify compliance with RFC 9116

Security.txt takes minutes to set up but can save hours — or days — when a researcher finds a vulnerability. It's a sign of security maturity and makes your organization easier to work with in the security community.