Confirm who receives and handles vulnerability reports, publish a small accurate security.txt file for each intended host, and verify its delivery and renewal process.
Someone finds a possible vulnerability on your website. Where should they report it? A general contact page may send the message to a marketing inbox, hide it behind an account login or leave the recipient unsure who owns the affected system. A small security.txt file gives researchers a recognised place to look for reporting information.
The useful part is the route behind the file: a reachable contact, a clear scope and someone responsible for handling reports. Publishing text that points to an abandoned inbox creates the appearance of a process without the process itself.
Understand the job of the file
The security.txt project focuses on making vulnerability-disclosure information easier to discover. Think of the file as a signpost. It is not a scanner, a firewall or a claim that the website has been independently reviewed.
Separate three decisions before implementation: where reports arrive, which systems you operate, and what testing you authorise through an appropriate policy. Do not assume that publishing a contact address automatically authorises intrusive testing or promises a reward.
For a fictional small publisher, the initial need may be simple: one website, a monitored role mailbox and a procedure for escalating a report to the developer or hosting operator. A public bug-bounty programme is a different commitment and should not be implied merely to make the page look established.
Name the owner before writing the file
Choose a role contact that can survive a staff change. Confirm who can read the inbox, who covers absences and who can reach the technical operator. If only one person has access, record a recovery and handover route rather than relying on their memory.
Use an authorised internal test message to confirm delivery and routing before publicising the address. Label it as a delivery check, include no exploit or personal data, and confirm the intended recipient can find it. This tests the contact route; it does not test the site’s security.
Agree how reports will be tracked. A restricted ticket with the affected host, received time, owner and next review date is more useful than an unassigned forwarded email. Keep unnecessary report details out of broad mailing lists and public chat channels.
Start with the required information
RFC 9116 requires Contact and Expires. Contact values use URI syntax; an email address therefore uses mailto:. Expires is a date-time after which the information is stale. The RFC recommends a value less than one year into the future, rather than imposing that interval as an absolute requirement.
The following is a hypothetical example for example.org, not an address to copy into your production site. Its expiry assumes a review on 14 October 2026. Set a suitable future date for your own review and renewal process.
Contact: mailto:security@example.org
Expires: 2027-04-14T12:00:00Z
Canonical: https://example.org/.well-known/security.txt
Policy: https://example.org/vulnerability-disclosure/Canonical and Policy are additional fields, not part of the two-field minimum. Canonical identifies an intended file URI; a signature is a separate authenticity mechanism. If you choose to sign the file, follow the RFC and maintain the signing process rather than adding decorative signature text.
Consult the IANA field registry when adding fields. Use registered names and check whether repeated appearances are permitted. Avoid inventing a field to express a policy that belongs on a readable policy page.
Make the policy match what you can support
Write the policy around your actual operation. Identify the systems you own or control, how a researcher should report a finding, and what information helps you investigate. Have the responsible owner review any language about testing permission, disclosure timing, rewards or legal assurances.
For the fictional publisher, a report template might request the affected URL, a concise description, harmless reproduction steps and the time observed. It should not ask someone to extract a database or collect other visitors’ information to prove the issue. State how to handle sensitive evidence through the supported contact route.
Do not promise continuous monitoring or a fixed response time that no one can meet. A modest accurate description is more credible than a copied enterprise policy. If you change the policy later, review whether its contact instructions still match the file and the inbox workflow.
Keep the host boundary explicit
The RFC’s file scope applies to the host used to retrieve it, not automatically to parent or sibling hosts. A file on example.org therefore does not by itself cover shop.example.org or www.example.org.
Inventory the public hosts you actually intend to cover. For each one, record its operator, reporting route and policy. A shop run by a separate provider may need a different escalation route; do not imply authority over the provider’s other customers or infrastructure.
It can be reasonable for multiple controlled hosts to point to the same maintained policy. Verify each host’s file independently and make the policy’s authorised scope clear. A redirect to the main website is not a substitute for deciding what the reporting process covers.
Publish plain text at the recognised location
For web services, RFC 9116 specifies HTTPS delivery at /.well-known/security.txt with text/plain and UTF-8. A root-level /security.txt may support legacy discovery, but the well-known location takes precedence when both exist.
Choose the serving mechanism that fits the site: a maintained static file, an application route or a supported platform setting. Confirm the target domain and environment before changing hosting configuration. Do not edit a neighbouring site’s document root simply because the same hosting account contains both websites.
A content-management system may otherwise return an HTML page, a login screen or a friendly error with a successful status. Inspect the actual public response. A browser displaying words is not enough to establish that the endpoint serves the intended text format.
Check the public response and the reporting journey
- Open the exact HTTPS well-known URL while signed out. Confirm it is reachable without an administrator session.
- Inspect the response status, Content-Type and body. Check the required fields and the current expiry.
- Follow the stated policy link and confirm that it names the intended systems and working reporting route.
- Check any redirect deliberately; verify that the final destination is controlled and expected.
- Repeat for each intended host, including the www form if it is in scope.
Keep a small release record with the checked URL, date, file revision and contact owner. A format validator can help find syntax mistakes, but it cannot establish that the mailbox is read or that the policy accurately describes authority over a system.
If the reporting route is a form, review its labels, errors and confirmation as well. Our website form accessibility guide provides a separate practical checklist. A researcher should not need to guess whether a report disappeared after submission.
Renew by reviewing, not merely changing the date
Set a reminder sufficiently before expiry to allow a real contact check. The owner should confirm that the mailbox still works, the named operator still has access and the policy still describes the current hosts. Only then update the expiry through the normal release process.
A fictional six-month review might include an inbox handover check, a public response check and a policy comparison against the current domain inventory. The interval is an operational choice for that example. A more frequently changing business may need earlier reviews after migrations, acquisitions or staffing changes.
Do not generate an indefinitely moving expiry on every request while leaving the underlying information unreviewed. A fresh-looking timestamp is poor evidence of a maintained reporting route. Retain an internal review record separate from what the public file displays.
Handle the first report without exposing it
When a report arrives, acknowledge and triage it through the process you actually adopted. Avoid opening unknown attachments or reproducing a destructive claim against production without an authorised plan. Escalate to the appropriate technical owner and keep access to the report limited.
Distinguish a genuine report from a demand for payment, and do not let a copied policy imply a bounty you never offered. If the report concerns a third-party system outside your authority, direct it appropriately rather than authorising investigation on the provider’s behalf.
Finish with a repeatable ownership record: who maintains the file, who receives reports, which hosts are covered and when the next review occurs. The value of security.txt is a discoverable, maintained reporting path. It does not replace the separate work of protecting and maintaining the website.
Sources and verification
Editorial review 2026-10-14. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- RFC 9116: A File Format to Aid in Security Vulnerability DisclosureChecked Required Contact and Expires fields, HTTPS well-known location, UTF-8 plain-text delivery, host scope, canonical information, signatures and expiry recommendation.
Limits: Informational RFC for disclosure contact information; not blanket testing permission, a bounty contract or a complete response programme. - IANA: security.txt FieldsChecked Registered field names, references and multiplicity information.
Limits: A field registry does not certify that a site's contact is monitored or policy is legally sufficient. - securitytxt.org: project overview and examplesChecked Project purpose and practical discoverability of vulnerability-reporting information.
Limits: An example or generator is a starting aid; the operator must own the contact, policy and maintenance process.