A security.txt file is useful when a person who finds a vulnerability can locate it, understand the reporting route and reach someone who responds. A syntactically valid file pointing to an abandoned mailbox does not meet that practical purpose. Treat the file as the entry point to a maintained disclosure process.
The standard defines a discoverable format for security contact information. It does not grant permission to test every system, promise a reward or replace the organisation's disclosure policy. Publish clear contact and policy information that matches the process you can actually support.
Publish at the well-known HTTPS location
The standard location is /.well-known/security.txt on the relevant web origin. Serve it over HTTPS with the appropriate plain-text content type and UTF-8 encoding. A historical root-level location may redirect to the well-known path, but the intended canonical location should be clear.
The security.txt validator reviews pasted file content. It can identify required fields and formatting issues, but it does not verify that your public URL serves the file or that the listed contact route reaches an active team.
Test the public deployment through the same CDN and routing layer that visitors use. A static file can be present in the repository while an application router serves an HTML fallback at its URL. Confirm status, content type and body from the actual endpoint.
Start with Contact and Expires
Contact tells reporters how to reach the organisation through a supported URI, such as a mailto address or an HTTPS reporting page. Expires tells readers when the information should be considered stale. Use an unambiguous timestamp in the standard's expected format.
Contact: mailto:security@example.com
Expires: 2027-04-01T00:00:00Z
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policy
Preferred-Languages: enThis is an illustrative file using a reserved example domain. Replace every destination with a verified route you operate. Do not publish a fictional mailbox merely to satisfy a validator; it creates a misleading reporting promise.
Choose an expiry that creates a realistic review cadence and follows the standard's guidance. The timestamp is not an automatic renewal mechanism. Assign an owner and a reminder before the file expires, then verify the contacts again during review.
| Field | Purpose | Verify |
|---|---|---|
| Contact | Reporting route | The mailbox or form reaches the responsible team |
| Expires | Freshness boundary | A review is scheduled before the timestamp |
| Canonical | Expected file location | The published URL matches the deployment |
| Policy | Disclosure process and scope | The page is clear, current and accessible |
| Encryption | Public encryption information | Key ownership, validity and usable instructions |
| Preferred-Languages | Languages the team can handle | The listed capability is real |
Test the complete reporting route
For a mailbox, verify that messages arrive, are routed to the right queue and are visible to the people responsible for triage. Check what happens during staff absence. A personal address tied to one employee can become a dead end when roles change.
For a form, test submission with a harmless synthetic report. Confirm the success message corresponds to actual delivery rather than only client-side validation. Keep attachments and sensitive data handling appropriate to the process, and avoid requiring unnecessary personal information from a reporter.
Do not send test messages to unrelated organisations while validating an example. Use your own authorised reporting route. The goal is to verify a channel you operate, not to create unsolicited security tickets elsewhere.
Make the linked policy useful before an incident
Describe which systems are in scope, how reports should be submitted and what information helps reproduce an issue. Explain expectations about privacy, data access and disruptive testing in language the organisation can stand behind. Avoid claiming a broad safe-harbour or reward programme unless it actually exists.
State realistic response expectations and keep them aligned with staffing. A promise of immediate response is not helpful if the mailbox is checked weekly. Reporters need a credible process and a way to understand what happens after submission.
Separate vulnerability disclosure from general customer support. A security route can receive noise, but its triage process should still identify credible reports promptly. Provide a suitable support link so routine account issues do not obscure the security queue.
Replace an expired file after a team change
Suppose a domain's file expires after the security lead leaves. The listed mailbox forwards to that person's account, and the policy page names an old programme. Updating only the Expires timestamp would make stale information appear current without repairing the route.
Assign a current owner, create or verify a team-managed contact and update the linked policy. Send a controlled test through the real route and confirm receipt in the current queue. Then publish the corrected file and inspect the public response.
Check cached copies and redirects if the canonical location changed. A root-level file and a well-known file can diverge if maintained separately. Prefer one authoritative source with clear routing so future updates do not leave conflicting instructions.
Record the review date, owner and test outcome internally. The public file should contain useful contact information, while the operational record explains how the organisation knows that information is maintained.
Publish encryption details only when the team can use them
An Encryption field can point to public key information or other supported encryption guidance. Verify that the key belongs to the reporting team, remains valid and is available at the listed location. A public key without a maintained private-key handling process can make reports unreadable.
Keep key rotation and contact rotation connected. If an old encrypted report arrives after rotation, the team needs a documented approach consistent with its retention and key-management rules. Do not promise decryption capability that has already been lost.
Explain how a reporter should use the key and which route accepts the encrypted material. Publishing a raw key URL alone may leave uncertainty about message format or attachments. Keep instructions concise but operationally complete.
Be precise about domains and copies
A file's scope follows the standard's rules for where it is retrieved. Do not assume that one file automatically describes every unrelated domain owned by a company. Publish or link appropriate information for each relevant service and keep the canonical declarations consistent.
Canonical information helps identify intended locations and can be important when copies are encountered. A copied file on another host should not silently be treated as an authoritative statement for that host without checking scope and canonical context.
If a hosting provider manages many customer domains, establish who owns disclosure for the platform and who owns each customer's application. The file should guide reporters to the right responsible party instead of implying authority over systems the operator does not control.
Monitor usefulness as well as syntax
Check the file's availability, expiry and linked destinations regularly. Include it in deployment checks so a routing rewrite or access-control change does not replace it with a login page. A public security contact should remain discoverable before a reporter needs an account.
Review contact ownership after organisational changes and test the route at a reasonable cadence. Track whether credible reports receive acknowledgement and reach an owner. Those process measures reveal failures a text validator cannot see.
Keep the file small and readable. It is a directory of security contact information, not a marketing page or a place for unsupported certification claims. Link to fuller policy details where necessary and preserve the standard field syntax.
Frequently asked questions
Does security.txt authorise penetration testing?
The file supplies contact and policy information. Authorisation depends on the actual policy and the system owner's permission. Do not infer broad testing permission merely from the file's presence or from a Contact field.
Is a Contact field alone enough?
The standard requires other information including Expires, and practical usefulness also depends on a working route. Validate the format, then verify publication and delivery. A syntactically accepted address that nobody monitors is not an effective disclosure process.
Can the validator confirm my mailbox works?
No. It analyses the supplied text. Test your own authorised contact route separately and confirm receipt with the responsible team. Do not interpret a valid mailto URI as proof of mailbox existence or operational ownership.
Should the file require login?
The discovery file should be publicly accessible at its intended location. A linked reporting process can have its own design, but unnecessary access barriers can prevent useful reports. Test the route from a fresh browser without an existing account.
What happens after Expires passes?
Readers should treat the information as stale under the standard's freshness model. Review the contacts and policy before extending the timestamp. Simply moving the date forward without checking the route defeats the purpose of the field.
Do I need an encryption key?
Provide encryption information if your process supports it and the team can maintain the keys and instructions. Do not add an unusable key to make the file look complete. A reliable contact route and clear handling process are essential.
What confirms the file is ready to publish?
Verify the required fields, public HTTPS location, plain-text response, canonical consistency, working contact route and current policy. Assign ownership for expiry review. The final result should help a real reporter reach a real team.