security.txt check
Enter a site to see whether it tells security researchers where to report a problem, and whether that file is in the right place, well formed and still in date. If there isn’t one, you can write it below.
Write a security.txt
Fill in what applies and copy the result. The file is put together inside this page: nothing you type here is sent to us.
An email address or the https:// address of a form. Use a shared mailbox, not a person: people leave.
A page that says what may be tested and what a reporter can expect from you.
Language codes separated by commas.
Adds a Canonical line, which ties the file to its address.
Preset to one year from today, the longest the standard recommends.
- Save the text as a file named
security.txt, encoded in UTF-8. - Upload it to a folder named
.well-knownat the root of the site, so that it answers athttps://your-domain/.well-known/security.txt. - Run the check above: the file must come back over HTTPS as
text/plain. - Put the expiry date in a calendar. An expired file is worse than none, because it looks abandoned.
A front door for bad news
Sooner or later, somebody outside your organization spots something wrong with your site: a page that shows other customers’ orders, a forgotten admin panel, a password reset that can be replayed. Most of these people want to tell you. The hard part is finding someone to tell. The contact form goes to sales, the support chat wants an order number, and nobody answers info@.
A security.txt file fixes that one problem. It’s a few lines of plain text at a fixed address, /.well-known/security.txt, saying where reports go and until when that information holds. The format was published as RFC 9116 in 2022. Scanners, bug bounty platforms and national security agencies read the file automatically when they have something to pass on.
Contact: mailto:security@example.com
Expires: 2027-01-31T00:00:00.000Z
Preferred-Languages: en, de
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policyWhat this check reads
Our server requests https://your-host/.well-known/security.txt, then the older address /security.txt at the root if the first one returns nothing. Redirects are followed. A reply with status 200 that turns out to be an HTML page counts as no file, since many sites answer every unknown address with their home page.
When there’s a file, we judge it on three things.
| Part | What must be true |
|---|---|
| How it is served | At the /.well-known/ address, over HTTPS, with Content-Type: text/plain. A redirect to another domain is pointed out. |
Contact | At least one, each a URI: mailto:, https:// or tel:. A bare email address without mailto: is an error. |
Expires | Exactly one, written as a full timestamp such as 2027-01-31T00:00:00.000Z, in the future. Expired is an error; fewer than 30 days left or more than a year ahead is a warning. |
| Optional fields | Encryption, Acknowledgments, Policy, Hiring and CSAF must be https:// addresses. Preferred-Languages appears once and holds language codes. Canonical must include the address the file was read from. |
Field names outside the standard are listed without penalty, since extensions are allowed. The check also says whether the text is wrapped in an OpenPGP cleartext signature. It doesn’t verify that signature.
The mistakes we see most
- An expired date
- Someone wrote the file once and forgot about it. RFC 9116 says an expired file shouldn’t be used, so a reporter is back to guessing. Renewing takes two minutes: confirm the contacts, move the date, publish.
- No
Expiresat all - Files written before 2022 followed a draft where the field was optional. It’s required now.
Contact: security@example.com- The value has to be a URI. Write
mailto:security@example.com. - The file at the root only
/security.txtis a fallback. Put the file in/.well-known/and redirect the old address to it.- A
Canonicalcopied from another site - If the field is there and doesn’t list the address the file is served from, the file contradicts itself.
Publishing one that you can keep alive
Start by deciding who reads the mailbox. A shared address such as security@ that reaches two people beats a named person. Then use the generator on this page. It adds mailto: where needed, formats the date and presets it one year ahead.
Upload the result to a folder named .well-known at the web root. Most servers send .txt files as text/plain without being told. If yours hides folders that start with a dot, add an exception. In nginx:
location = /.well-known/security.txt {
default_type text/plain;
charset utf-8;
}Signing is optional. With GnuPG, gpg --clearsign security.txt produces a signed version to publish in its place. Include a Canonical line before signing so that the signature covers the address too.
This page reads one host, once. It can’t tell whether anyone answers at the contact address, whether the linked policy exists, or whether the signature is genuine. A missing file isn’t a security flaw and doesn’t lower any grade here.
Questions people ask
Is a missing security.txt a vulnerability?
No. The file is a courtesy that makes reporting easier, and it protects nothing by itself. Some automated scanners list its absence as a low-severity finding. Take that as a suggestion.
Where exactly does security.txt go?
At https://your-domain/.well-known/security.txt, served over HTTPS as plain text. Each host is separate, so a file on example.com doesn’t cover app.example.com.
Will publishing a contact address attract spam or fake bug reports?
Expect some automated low-value reports, often asking for a reward. A short policy page that says what you consider in scope, and whether you pay bounties, filters out most of them. Pointing Contact at a web form instead of a mailbox helps too.
How long should the Expires date be?
Less than a year ahead, as the RFC recommends. The date is a promise that the contacts were correct when the file was last reviewed, which is why it’s supposed to be short. Set a reminder a month before it passes.
Do I need to sign the file with PGP?
No. A signature helps a reader confirm that the file wasn’t altered on a compromised server, and it only works if your public key can be obtained somewhere else. Plenty of valid files are unsigned.
What is the difference between security.txt and robots.txt?
Both are plain text files at a known address, read by software. robots.txt tells crawlers which pages to leave alone. security.txt tells people who found a security problem how to reach you. Neither one enforces anything.