Security.txt Checker Guide: Verify Your Site Invites Security Reports Properly
When a security researcher finds a vulnerability in a website, the first problem is often not the vulnerability itself but the question of who to tell. Without a published contact for security reports, a researcher may report the issue through a general contact form, a social media message, or not at all, and a vulnerability that could have been fixed quietly can instead be disclosed publicly or exploited. A security.txt file solves that problem: it is a small, standard file placed on a website that says who to contact about security issues and how. The Security.txt Checker verifies that such a file exists, is reachable, and follows the standard, so the invitation it extends actually works.
The file lives at a well-known address on the site, under the .well-known directory, which is where researchers and automated tools look for it first. Its contents are simple lines, each naming a field and a value: a contact address or web form for reports, an expiry date after which the file should be considered stale, and optionally a link to the site's security policy, a note about which languages reports are accepted in, and a link to a public key for encrypted reports. The simplicity is deliberate. A researcher who finds a problem at two in the morning should be able to find the contact in seconds, without navigating a site's structure or guessing which form reaches a human.
A checker matters because a security.txt file fails in ways that are invisible to its owner. The file can be published in the wrong location, so tools looking in the standard place never find it. It can contain a contact address that no longer works, so reports go nowhere. It can be missing its expiry date, so a researcher cannot tell whether the information is current. It can be written in a format that a strict reader rejects, even though it looks fine to a human eye. Each of these failures defeats the file's purpose while leaving the owner believing the invitation is open, and a checker is what closes that gap between belief and reality.
How a security.txt file is checked
The check starts with location. The standard location is the .well-known directory at the site root, and a secondary location at the site root itself is also accepted by convention, though the .well-known address is the one tools check first. The checker confirms the file is retrievable from the standard location and reports if it is only found elsewhere, or not found at all, because a file that researchers cannot find is the same as no file.
The check then reads the file's fields. The contact field is required, and there can be several, such as an email address and a web form. The checker confirms at least one contact is present and that each contact is well-formed, meaning an email address looks like an address and a web address looks like an address. The expiry field is also required by the standard, and the checker confirms it is present and written as a proper date and time, and warns if the date has already passed, because an expired file tells researchers the information may be stale. Optional fields are checked for form as well: a policy link should be a valid address, a language tag should be a real language code, and an encryption key link should point at a retrievable key.
The checker works on the file's content as supplied or as found at a public address. It does not need credentials, it does not log into anything, and it does not test whether the contact address is monitored by a human; that last question can only be answered by sending a test report through the proper channel or by confirming internally that the mailbox is watched. What the checker guarantees is narrower and still valuable: the file is where researchers look, it is well-formed, its required fields are present, and its expiry date has not passed. A file that passes those checks is ready to receive reports, and a file that fails them has a specific, fixable problem.
Worked example
Consider a small software company that publishes a security.txt file after reading about the standard. The file contains a contact email address and a link to the company's security policy, and it is placed in the .well-known directory. The owner runs the checker and receives two findings. First, the file has no expiry field, so it fails the standard's requirement and gives researchers no way to judge whether the contact is current. Second, the contact email address belongs to a former employee whose mailbox is no longer monitored, a fact the owner discovers only because the checker prompted a review of the contact itself.
The fixes are quick. The owner adds an expiry date one year ahead, sets a calendar reminder to renew the file before that date, and replaces the contact with a shared security mailbox that several team members monitor. Re-running the checker shows a clean result: the file is in the standard location, the contact is well-formed, and the expiry date is in the future. The owner then sends a test message to the new mailbox to confirm it is genuinely monitored, closing the one gap the checker cannot test. The whole exercise takes under an hour, and the company now has a working channel for the next researcher who finds a problem, instead of a file that looked right and led nowhere.
The example also shows the maintenance habit the file requires. An expiry date is a promise to review the file, and the review should confirm the contact still works, the policy link still resolves, and the encryption key, if one is published, is still current. Treating the expiry date as a real deadline, with a reminder set before it, is what keeps the file trustworthy over time rather than letting it decay into a stale invitation.
Mistakes to avoid
The first mistake is publishing the file in the wrong location, where researchers and tools will not look for it. The second is omitting the expiry date, which leaves the file's freshness unknowable. The third is listing a contact that nobody monitors, which is worse than no file at all, because it creates a false sense of coverage. The fourth is never renewing the file, so an expiry date passes and the file signals staleness. The fifth is including sensitive information in the file, such as internal addresses or credentials, which do not belong in a public document; the file should contain only public contact and policy information. The sixth is assuming the checker proves reports will be handled, when only a monitored mailbox and a response process can do that.
Putting it into practice
Publish the file in the .well-known directory with at least one monitored contact and an expiry date no more than a year ahead, then run the checker and fix every finding. Send a test message to the contact to confirm it is monitored, and set a reminder to review the file before its expiry date. Re-check the file whenever the contact, the policy, or the encryption key changes, and treat the checker as part of the publishing routine for the file rather than a one-time task.
For related tools, the Security.txt Generator drafts the file itself, the HTTP Headers Checker reviews the other public signals your site sends, and the companion guide on HTTP security headers covers the wider set of site protections. A security.txt file is a small courtesy to the people who find your problems, and a checker is what makes sure that courtesy actually reaches them.
Key points
- A security.txt file tells researchers who to contact about vulnerabilities and how, from a standard location on your site
- A checker confirms the file is reachable in the standard location, well-formed, and has its required fields
- The contact field and the expiry field are both required, and an expired file signals stale information
- A listed contact must be genuinely monitored; the checker verifies form, not whether a human reads the mailbox
- Set a reminder before the expiry date and re-check the file whenever its contents change
In short: publish the file where researchers look, keep its contact monitored and its expiry date current, and verify it with a checker before you rely on it.