security.txt Generator

Generate a standards-compliant security.txt file (RFC 9116) for your website. Paste in one or more contact URIs, pick an expiry date, add optional fields like Encryption, Policy, and Canonical — and get a ready-to-deploy file you can place at /.well-known/security.txt.

How to use the security.txt Generator

Fill in at least one Contact URI — this is the only mandatory field besides Expires. Each contact goes on its own line and must be either a mailto: or https: URI. The generator repeats the Contact: directive once per URI, as required by RFC 9116.

Set Expires to a date less than one year from today. RFC 9116 requires this field, and security researchers may ignore your file if it is expired or missing. The date is emitted in ISO 8601 format with a trailing Z (e.g., 2026-12-31T00:00:00Z).

Optional fields: Encryption — a URL pointing to your PGP public key so researchers can submit reports confidentially. Acknowledgments — a URL to your hall-of-fame page. Preferred-Languages — a comma-separated list of BCP 47 language tags (e.g., en, de). Canonical — the authoritative URL of this file (important if you mirror it). Policy — a link to your full security or responsible-disclosure policy. Hiring — a link to security job openings.

Once generated, save the output as security.txt and serve it at https://example.com/.well-known/security.txt. Optionally PGP-sign the file (clearsign with your key) for authenticity — the spec allows but does not require a signature.

What is security.txt?

security.txt is a proposed standard (RFC 9116, published April 2022) that lets organizations publish a machine-readable security contact file at a well-known location on their website. It is inspired by robots.txt and follows the same philosophy: place a simple text file at a predictable URL so that automated tools and human researchers alike know exactly where to direct vulnerability reports. Without it, security researchers often spend hours hunting for a contact address and frequently give up — meaning real bugs go unreported.

The file must live at https://example.com/.well-known/security.txt (the /.well-known/ directory is defined by RFC 8615). It is served as plain text (Content-Type: text/plain). The minimum viable file needs only two fields: Contact: and Expires:. The Expires: field is mandatory so that stale files with outdated contact addresses do not mislead researchers; the spec recommends updating the file at least once per year. Optional fields let you point to a PGP key for encrypted reports, a responsible-disclosure policy, acknowledgment pages, and even job listings for your security team.

For higher assurance, you can PGP-clearsign the file with your organization's key. Researchers can then verify that the contact information genuinely comes from you and has not been tampered with. The Canonical: field helps prevent confusion when the file is mirrored or cached at multiple URLs. If you operate multiple domains, each needs its own security.txt — there is no cross-domain inheritance.

Common use cases

• Responsible disclosure — Give security researchers a clear, RFC-compliant channel to report vulnerabilities without having to hunt for a contact address.
• Bug-bounty programs — Point the Policy: field at your HackerOne or Bugcrowd program page so automated scanners can find it.
• Encrypted submissions — Include your PGP key URL via the Encryption: field so researchers can submit sensitive PoCs confidentially.
• Multi-team organizations — List multiple Contact: lines — one for a triage inbox, one for a web form — so reports reach the right team.
• Compliance and trust signals — Frameworks like ISO 27001 and SOC 2 increasingly expect documented security contact procedures; security.txt satisfies that requirement cheaply.
• Security hiring — Use the Hiring: field to surface security engineering roles to the exact audience already inspecting your site's security posture.