security.txt Explained: How to Build a Vulnerability Disclosure Process Researchers Can Actually Use

A security researcher finds a vulnerability on your website. What happens next depends less on the technical sophistication of your security team than many organizations expect. If the researcher cannot find a trustworthy reporting address, does not know which systems are in scope, or cannot tell whether a security mailbox is still monitored, a useful disclosure can turn into delay, confusion, public escalation, or a report sent to the wrong person.

The security.txt standard exists to reduce that friction. Defined by RFC 9116, it gives organizations a machine-readable way to publish vulnerability disclosure contact information and related policy details at a predictable location. It does not fix vulnerabilities. It does not authorize security testing. It does not create a bug bounty. What it does is give researchers a clearer path to tell you when they have found something that needs attention.

For organizations building a mature public security posture, that small file can be surprisingly useful. The real value, however, comes from the response process behind it. A perfectly formatted security.txt file pointing to an abandoned inbox is worse than a simple file backed by a working triage process.

What is security.txt?

security.txt is a plain-text file that publishes information about an organization's vulnerability disclosure practices. RFC 9116 defines the format so researchers and automated tools can find consistent fields such as a security contact, expiration time, policy link, preferred languages, and other optional information.

For web publishing, the primary standardized location is:

https://example.com/.well-known/security.txt

RFC 9116 also recognizes the historical top-level location for compatibility, but if both exist, the file under /.well-known/ takes precedence. The file is retrieved over HTTPS and should be served as plain text using UTF-8.

Vulnify's security.txt Checker is designed to verify whether this public disclosure information is present, formatted sensibly, and still fresh. It looks at RFC-style fields, stale policy signals, and common publication problems.

The fields every valid security.txt file needs

RFC 9116 requires at least one Contact field and exactly one Expires field. Other fields are optional but can make the disclosure workflow much clearer.

Contact

Contact tells the researcher where to report a security issue. It can appear more than once, and the order expresses priority. A dedicated security mailbox is common:

Contact: mailto:security@example.com

You can also provide an HTTPS contact page or reporting portal if that is the actual preferred workflow.

The important word is actual. Do not publish a mailbox that nobody monitors. Do not point to a general support form if security reports disappear into a customer-service queue with no escalation path. The field should lead directly into a process that can recognize and route vulnerability disclosures.

Expires

Expires signals when the contents of the file should be considered stale. RFC 9116 requires this field. The value is a date and time in the format required by the specification.

Expires: 2027-03-31T23:59:59Z

The point is not to predict when your security process will stop existing. The point is to force periodic review. Contact addresses, policy URLs, keys, vendors, and scope can change. An expiration field gives maintainers a reason to revalidate the file rather than publishing it once and forgetting it.

Useful optional fields

Policy

The Policy field links to your vulnerability disclosure policy. This is where you can explain scope, safe-harbor language if your legal team supports it, prohibited activities, expected communication, response expectations, and how researchers should handle sensitive data.

Policy: https://example.com/security/disclosure-policy

A useful policy should be written for researchers, not as a generic legal disclaimer. It should clearly explain what the organization wants people to do when they discover a possible issue.

Preferred-Languages

If your security team can handle reports in specific languages, say so:

Preferred-Languages: en, th

This helps researchers choose the most useful language for the initial report and can reduce unnecessary translation friction.

Canonical

Canonical identifies the authoritative URL for the file. For a web URL, RFC 9116 requires HTTPS. A common example is:

Canonical: https://example.com/.well-known/security.txt

If you publish the same content in multiple places or use redirects, a correct canonical value helps clarify which file is intended to be authoritative.

Encryption

The optional Encryption field can point researchers to a public key or instructions for sending encrypted vulnerability reports. This can be useful when reports may contain sensitive evidence, credentials, or customer data.

Only publish encryption information that your team can actually use. A stale PGP key with no private-key owner creates more friction rather than less.

Acknowledgments

The optional Acknowledgments field can link to a page recognizing researchers who previously disclosed security issues responsibly. This is not required, and organizations should avoid publishing vulnerability details that could create additional risk. Used carefully, it can show that the disclosure process is active and that constructive research is valued.

A clean security.txt example

A simple file can be enough:

Contact: mailto:security@example.com
Policy: https://example.com/security/disclosure-policy
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
Expires: 2027-03-31T23:59:59Z

If your organization needs encrypted reporting, add the appropriate Encryption field. If you maintain a recognition page, add Acknowledgments. Do not add fields simply because they look professional. Every published value should lead somewhere current and operational.

security.txt is not permission to test

This is one of the most important points to communicate internally. Publishing a security.txt file does not automatically authorize anyone to perform invasive testing against your systems. RFC 9116 is a disclosure mechanism, not an authorization contract.

If you want to define what testing is allowed, state that in a vulnerability disclosure policy or bug bounty program with clear legal and technical scope. A policy can explain whether automated scanning, authentication testing, social engineering, denial-of-service testing, data access, or testing against third-party systems is allowed or prohibited.

Likewise, researchers should not assume that a listed contact creates safe harbor beyond what the organization explicitly states. The disclosure file tells people where to communicate. The policy tells them what the organization permits and expects.

security.txt is not a bug bounty

A bug bounty program offers rewards under defined terms. A vulnerability disclosure program provides a channel and process for receiving reports. The two can overlap, but they are not the same thing.

A small business can publish security.txt and a disclosure policy without offering payment. In that case, be clear. Do not imply rewards if none exist. If rewards are available only through a third-party bounty platform, link to that program and explain that eligibility depends on its terms.

Clarity prevents unnecessary conflict and helps researchers decide whether to spend time testing within your published scope.

Build the process behind the file

The disclosure file is only the front door. The operational process should answer what happens after a report arrives.

1. Monitor the channel

The security mailbox or reporting portal should be monitored consistently. Avoid tying the only security contact to one employee. Use a shared queue with clear ownership, backups, and access controls.

2. Acknowledge receipt

A researcher should know that the report reached the right team. The acknowledgment does not need to confirm the vulnerability immediately. It should confirm receipt, provide a tracking reference if your workflow supports one, and explain when the reporter can expect the next update.

3. Triage the report

Determine whether the issue is reproducible, in scope, and security relevant. Capture the affected asset, vulnerability class, evidence, possible impact, reporter contact, and internal owner.

Do not dismiss a report because the initial wording is imperfect. Researchers have different levels of experience. Focus first on whether the underlying behavior is real.

4. Contain urgent risk

If the report exposes credentials, sensitive files, active exploitation, or a high-impact weakness, treat it as an incident rather than waiting for the normal remediation cycle. Remove public exposure, rotate affected secrets, restrict access, or apply compensating controls as appropriate.

5. Fix and verify

Assign remediation to the team that owns the affected system. After the fix is deployed, verify the behavior again. Depending on the issue, verification may involve code review, a focused test, or a broader security scan.

Vulnify's Website Security Scanner can support broader public-surface validation after fixes, while focused tools can help with specific configuration categories. For higher-risk cases where evidence-backed automated active testing is appropriate and authorized, Vulnify also provides an Automated Penetration Test workflow with explicit target authorization before testing begins.

6. Close the loop with the reporter

Once the issue is resolved or a decision is made, communicate the outcome at a level that is safe and appropriate. Good disclosure relationships depend on predictable communication, even when a report is not accepted as a vulnerability.

Understand security.txt scope and subdomains

RFC 9116 states that a security.txt file applies to the domain or IP address used to retrieve it, not automatically to parent domains or subdomains. That matters for organizations with many public services.

A file at:

https://example.com/.well-known/security.txt

does not automatically mean the same file governs:

https://shop.example.com/.well-known/security.txt
https://api.example.com/.well-known/security.txt

If you want consistent disclosure handling across multiple hosts, make sure the publication strategy and policy clearly reflect that architecture. You can publish equivalent files where needed and use the policy page to explain organizational scope.

Common security.txt mistakes

Expired Expires value

An expired file signals that nobody has reviewed the disclosure information recently. Update the contents first, then set a new review period. Do not simply push the date forward without confirming contacts and links.

Dead or unmonitored contact

This is the most damaging operational mistake. Test the contact path periodically from outside the organization.

Publishing only at a non-standard location

A footer link to a security page is useful, but automated discovery expects the well-known location defined by the standard. Publish the file where researchers and tools will look for it.

Confusing redirects or multiple copies

If you redirect from a legacy root file, make the final destination clear and use the canonical field appropriately. Avoid different copies with conflicting contact information.

Sending reports to generic support

General support teams may close, downgrade, or mishandle technically complex reports. If support is the intake channel, train the team and create a mandatory escalation route for security keywords and vulnerability reports.

A polished policy with no internal process

The public page is not the control. Ownership, triage, remediation, communication, and validation are the control.

How to validate your security.txt publication

Start by opening the exact well-known URL over HTTPS and confirming that it returns the expected text file. Check that the contact works, the policy URL loads, the expiration date is in the future, and any canonical or encryption URLs are correct.

Then run the Vulnify security.txt Checker. It is intended to verify disclosure publication, RFC-style fields, and policy freshness. Use the result to separate simple formatting problems from process problems.

If the review uncovers a wider deployment-hygiene concern, such as unexpected public files or administrative paths, use the Exposed Paths Checker for a focused public-path review. If you want a wider assessment of the public website after fixing the disclosure process, run the Website Security Scanner.

security.txt and disclosure-readiness checklist

• Publish /.well-known/security.txt over HTTPS.
• Include at least one working Contact field.
• Include one current Expires field.
• Link to a clear vulnerability disclosure policy where possible.
• Use Preferred-Languages when it helps researchers communicate effectively.
• Use Canonical when appropriate and ensure the URL matches the authoritative file.
• Publish encryption information only if the team can actively use it.
• Test the reporting channel from outside the organization.
• Define who acknowledges, triages, owns, and closes reports.
• Escalate reports involving active compromise or sensitive exposure into incident response.
• Revalidate the file before its expiration date.
• Document what systems and testing activities are in scope in the disclosure policy.

When to review the file

Do not wait until the expiration date if important organizational details change. Review security.txt after security-team changes, mergers, domain migrations, new bug bounty providers, mailbox changes, key rotation, disclosure-policy updates, and major restructuring of public services.

A recurring quarterly or semiannual check is reasonable for many organizations, with the RFC expiration date acting as an additional enforcement mechanism. The exact cadence matters less than making sure somebody owns it.

Conclusion

security.txt is a small technical standard with an operational purpose: make it easier for security researchers to reach the right people before a vulnerability becomes a larger problem. Its value is not in the file alone. Its value comes from connecting a predictable public contact point to a real internal disclosure process.

Publish the file at the standard location, keep the required fields current, write a clear disclosure policy, and make sure the reporting channel is actively monitored. Then test the process rather than assuming the configuration works. Vulnify's security.txt Checker can help validate the public file, while the Website Security Scanner and authorized Automated Penetration Test workflows can support the technical follow-up when a broader security assessment is needed.