# security.txt file exists

- **Pattern:** `ab-000021` (`security-headers.basic-hygiene.security-txt`)
- **Severity:** info
- **Lifecycle:** active
- **Last modified:** 2026-04-17
- **Canonical URL:** https://auditbuffet.com/patterns/ab-000021
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-000021)

## Why it matters

Without a `security.txt`, researchers who discover vulnerabilities in your app have no official channel to report them — they either give up, post publicly, or sell the finding. RFC 9116 defines the standard that security teams, automated scanners, and responsible-disclosure platforms use to find contact information. ISO 27001:2022 A.5.5 includes coordinated vulnerability disclosure as a required control for information security management. A missing `security.txt` means a researcher who found your SQL injection is more likely to submit it to a bug bounty aggregator or post it to social media than reach you first — costing you the ability to patch quietly.

## Severity rationale

Info because the absence of security.txt does not create a vulnerability, but it eliminates the responsible-disclosure channel that lets you learn about real vulnerabilities before they're exploited.

## Remediation

Create `public/.well-known/security.txt` with at least a `Contact:` directive and an `Expires:` date per RFC 9116. The file is served as a static asset by Next.js automatically.

```
# public/.well-known/security.txt
Contact: mailto:security@yoursite.com
Expires: 2026-12-31T23:59:59Z
Preferred-Languages: en
Policy: https://yoursite.com/security-policy
```

Set `Expires` about a year out and update it annually. If you have a HackerOne or Bugcrowd program, use that URL as the `Contact:` value instead of a raw email. Verify the file is accessible at `https://yoursite.com/.well-known/security.txt` after deployment.

## Detection

- **ID:** `security-txt`
- **Severity:** `info`
- **What to look for:** Check for `public/.well-known/security.txt` or a route that serves `/.well-known/security.txt`. Enumerate all RFC 9116 fields present in the file (Contact, Expires, Encryption, Acknowledgments, Preferred-Languages, Canonical, Policy).
- **Pass criteria:** A `security.txt` file exists at `public/.well-known/security.txt` (or is served via a route handler at `/.well-known/security.txt`) and contains at least 2 required fields: a `Contact:` directive with a valid `mailto:` or `https://` URI and an `Expires:` directive per RFC 9116. The file should follow RFC 9116 format.
- **Fail criteria:** No security.txt file found.
- **Skip (N/A) when:** Never — every web project benefits from a security.txt.
- **Detail on fail:** `"No security.txt found at public/.well-known/security.txt or as a generated route"`
- **Remediation:** security.txt (RFC 9116) tells security researchers how to report vulnerabilities in your project. Create `public/.well-known/security.txt`:

  ```
  Contact: mailto:security@yoursite.com
  Preferred-Languages: en
  ```

  This is a low-effort improvement that shows security awareness and helps researchers help you.

---

## External references

- external RFC-9116 — https://datatracker.ietf.org/doc/html/rfc9116
- iso-27001 A.5.5

Taxons: operational-readiness

HTML version: https://auditbuffet.com/patterns/ab-000021