What Is a security.txt File? RFC 9116 Setup and Validation

Updated on Oct 19, 2026

7 min read

A security contact file for a website

A security.txt file gives security researchers a standard place to find an organization’s vulnerability-reporting contact and disclosure policy. If you operate a website, API, or other internet-facing service, publishing one can make it easier for a researcher to report a problem to the right team. The file does not detect vulnerabilities or run a disclosure program for you: it advertises a contact route that your organization must keep working.

What Is a security.txt File?

security.txt is a public, plain-text file that lists security-reporting information in a standardized format defined by RFC 9116. A researcher can request it from the well-known path on a domain, usually https://example.com/.well-known/security.txt, then use its contact and policy details to report a suspected issue.

Two fields are required: at least one Contact and an Expires timestamp. Other fields can point to a disclosure policy, a public encryption key, or related resources. The file is published over HTTPS and is readable by people and automated tools.

The Problem It Solves

Without a clear reporting route, a researcher may have to guess whether to contact support, sales, an administrator, or a generic mailbox. Reports can be delayed, misrouted, or sent through a channel that is not monitored. This is especially difficult when an organization operates several websites or services.

A security.txt file reduces that discovery problem, but it is only one part of a responsible disclosure process. Your team still needs to monitor its contact method, assess reports, coordinate fixes, and explain what testing is authorized. The OWASP Vulnerability Disclosure Cheat Sheet describes the broader process and policy considerations.

How security.txt Works

The flow is straightforward:

Researcher identifies a service → requests its HTTPS /.well-known/security.txt file → reads the listed contact and policy → submits a report through the stated channel → the organization triages and responds.

The file is a static discovery mechanism, not an authentication or ticketing protocol. It does not prove that a report is valid, protect a report sent to an unencrypted email address, or ensure that anyone will respond. If you list an email address, keep it monitored; if you list a web form, make sure it accepts reports without requiring an account the reporter cannot create.

The standard path is /.well-known/security.txt, following RFC 8615 on well-known URIs. The file applies to the domain or IP address used to retrieve it; it does not automatically cover parent domains or subdomains. Publish a suitable file for each hostname you want to cover. For compatibility with older clients, a site may also expose a top-level /security.txt, but the well-known location takes precedence when both exist.

Components and Variants

RFC 9116 defines these fields. Field names are followed by a colon and a value; the file is UTF-8 plain text.

Field	Requirement	Purpose
`Contact`	Required; include one or more	Gives a reporting method, such as a `mailto:` address, telephone number, or HTTPS page.
`Expires`	Required	Gives the date and time after which the information is stale, in RFC 3339 format. The RFC recommends an expiry less than a year in the future.
`Canonical`	Optional	Identifies the canonical HTTPS URI for this file.
`Policy`	Optional	Links to the vulnerability disclosure policy, including scope and reporting expectations.
`Encryption`	Optional	Links to a public key for encrypted communication; put the key at the linked location, not in this field.
`Preferred-Languages`	Optional	Lists languages the team can use to handle reports, such as `en` or `en, fr`.
`Acknowledgments`	Optional	Links to a page recognizing researchers who have contributed reports.
`Hiring`	Optional	Links to security-related job opportunities.

You do not need to publish every optional field. Prioritize a working contact and a clear policy. Only publish an encryption link if the private key is protected and someone can decrypt and process incoming reports.

Real-World Use Cases

A public website: A monitored alias such as [email protected] provides a direct route for researchers who find an issue.
An API or product hostname: A policy page can describe which endpoints are in scope and how to submit a reproducible report. Publish a file on that hostname rather than assuming the organization-wide root domain covers it.
A team handling sensitive reports: An encryption key can let researchers protect the report in transit, while the policy explains how to obtain the key and what information to include.
An organization with distributed security teams: Preferred languages and a maintained acknowledgment page can clarify communication and recognition practices.

These examples work only when the listed paths, mailboxes, and processes are maintained. An outdated contact can be worse than no useful direction because it gives the researcher a false destination.

Practical Considerations and Setup

Before publishing, decide who owns the inbox or form, who can triage reports, and how the team will acknowledge and route them. Make the disclosure policy agree with the actual response process. Publishing a file does not grant permission to probe or test systems; RFC 9116 explicitly cautions against treating it as implied authorization. Organizations can use responsible-disclosure guidance such as the EFF’s vulnerability disclosure resources when developing their process.

For a static site, create the file in the web server’s document root at .well-known/security.txt. In Astro, for example, put it at public/.well-known/security.txt so it is copied to that URL on deployment:

Contact: mailto:[email protected]
Expires: YYYY-MM-DDTHH:MM:SSZ
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security
Encryption: https://example.com/pgp-key.txt
Preferred-Languages: en
Acknowledgments: https://example.com/security/thanks

Replace the example domain, contact details, and Expires placeholder before deployment. Expires must be a real future RFC 3339 date-time, for example in the form YYYY-MM-DDTHH:MM:SSZ; renew it before it becomes stale. The Canonical value should match the HTTPS URL that serves the file. Do not list an encryption key unless the organization can safely manage its corresponding private key.

After deployment, request the public URL and inspect both the response and body:

curl -fsS -D - -o /dev/null https://example.com/.well-known/security.txt
curl -fsS https://example.com/.well-known/security.txt

Confirm that the request succeeds over HTTPS, returns the intended file rather than an application error page, and includes at least one valid Contact and a current Expires. Check every listed URI and verify that the contact can actually receive a test message. If you also publish /security.txt for compatibility, ensure it redirects to or matches the canonical file.

Keep the mailbox or web form monitored, restrict access to sensitive reports, and set a reminder to renew the expiry date. Review the file whenever contacts, policy scope, keys, or supported languages change. RFC 9116 also discusses stale or compromised files, redirects, report spam, and the risks of placing files in multi-tenant hosting environments.

Common Misconceptions

It is not a vulnerability scanner. The file does not assess a website’s security or fix a flaw.
It is not a disclosure program by itself. A contact line cannot replace a response owner, scope, triage process, or handling policy.
It does not authorize security testing. Researchers and site operators must follow applicable authorization and scope rules. A published file is not permission to test.
It does not control search indexing. Unlike a robots.txt file, security.txt communicates security-reporting information; it is not an SEO or access-control mechanism.
It is not an arbitrary list of optional fields. Contact and Expires are required by RFC 9116; other registered fields are optional.

Web security best practices explains the wider controls that protect an application.
Penetration testing methodology covers authorized testing and structured assessment.
Security incident response describes how to triage, contain, and learn from security events.
OWASP Top 10 security risks introduces common application-security risks.