#334 · Developer Tool

Security.txt Generator

Generate a security.txt disclosure file from structured contact and policy details. The builder validates contact schemes, normalizes an RFC 3339 expiration time, orders fields consistently, and adds optional Canonical, Encryption, Acknowledgments, Hiring, and Preferred-Languages entries. The result is ready to review and publish under /.well-known/security.txt. It deliberately does not invent contact addresses or claim that the file is cryptographically signed.

Developer Input

Contact settings
Ad space

How to use this developer tool

  1. Paste the contact settings or load the included sample.
  2. Adjust any tool-specific option shown below the input.
  3. Select Generate security.txt or press Ctrl/Cmd + Enter.
  4. Review the summary and findings, then copy or download the output.

What this developer tool does

Reads key=value lines, requires Contact and Expires, validates URL or mailto fields, then emits RFC 9116 field names in a stable order.

Reads key=value lines, requires Contact and Expires, validates URL or mailto fields, then emits RFC 9116 field names in a stable order.

Publish the same content at the HTTPS Canonical URL and renew Expires before it passes.

Example

Input

contact=mailto:security@example.com
expires=2027-07-19T00:00:00Z
canonical=https://example.com/.well-known/security.txt
languages=en,ko
policy=https://example.com/security-policy

Output

Contact: mailto:security@example.com
Expires: 2027-07-19T00:00:00.000Z
Preferred-Languages: en, ko
Canonical: https://example.com/.well-known/security.txt

Use cases

  • Review a deployment before changing production response headers.
  • Compare application and reverse-proxy configuration.
  • Create a reproducible finding for a security review or pull request.
  • Teach the practical effect of Security.txt settings.

Tips for reliable output

  • Use the complete header value, including repeated fields.
  • Test the final response after CDN and proxy processing.
  • Keep a copy of the before and after output for review.
  • Do not treat a passing result as a penetration test.
  • Recheck after framework, server, or browser-policy updates.

Processing details

Repeat contact= lines to provide multiple reporting channels. Comma-separated languages are normalized to a readable list.

OpenPGP signing is not performed. If your disclosure process requires a signature, sign the generated bytes after final review.

Frequently asked questions

Where should RFC 9116 security.txt be published?

The checker reports this directly from the supplied contact settings and shows the relevant value in its output.

Which URI schemes are allowed in a Contact field?

Use the result together with the browser and server behavior you support; the page does not make remote requests.

How far in the future can security.txt Expires be set?

Review the generated finding before deployment, especially when proxies or CDNs can alter headers.

Should a security.txt file include a Canonical field?

The implemented rule follows current HTTP security-header practice and flags values it cannot recognize.

Can the generated security.txt be PGP signed?

Retest with the exact production response because small header changes can affect the conclusion.

Checks and output

StageWhat is reported
ParseRecognized input fields and values
ValidateInvalid, missing, or conflicting settings
ExportText, CSV, and JSON when structured data is available

HTTP & Security Headers

Browse more tools for HTTP behavior, browser policies, cookies, CORS, CSP, and response-header security.

View HTTP & Security Headers