Free tool · Reads one public file · Nothing stored
If someone found a flaw in your site, could they tell you?
A security.txt file is the standard front door for reporting a vulnerability to a business — the "in case of emergency" card for your website. Check whether yours exists and holds up to RFC 9116.
Why bother
The difference between a quiet heads-up and a public surprise.
When a good-faith hacker finds a hole in your site, what they do next depends on whether they can find you. With a security.txt, they email the right person and you fix it quietly. Without one, they give up, email a sales address that ignores it, or post it publicly. It costs nothing to publish and it signals that you take security seriously.
Who uses it
security.txt is an IETF standard (RFC 9116). U.S. federal agencies, Google, GitHub, and most security-mature companies publish one. For a small business, it is one of the cheapest credibility signals available — and a common finding we clean up during a website security audit.
Straight answers
What is security.txt?
It is a small text file at /.well-known/security.txt that tells a security researcher how to report a vulnerability to you — a contact address, when the file expires, and optionally a disclosure policy and encryption key. It is a published standard (RFC 9116) used by governments, Google, GitHub, and most security-mature organizations. Think of it as the "in case of emergency" card for your website.
Is not having one a security problem?
Not a vulnerability in itself — your site is not less safe without it. But it is a maturity signal, and a practical one: when a researcher or a good-faith hacker finds a flaw in your site, security.txt is how they reach the right person instead of giving up, posting it publicly, or emailing a sales address that ignores it. For a business that takes security seriously, it is a cheap, standard thing to get right.
What makes a good one?
A Contact field (required), an Expires date in the future (required by RFC 9116), and ideally a Canonical URL and a link to your disclosure Policy. This tool grades yours against those. The most common mistake is an expired file — an Expires date in the past reads as neglected.
How does the check work — is anything stored?
We fetch the public file from your site once, from our edge, read only that file, and store nothing. There is no signup. It is the same file any visitor could request directly.
Small file, real signal.
Publishing a correct security.txt — and the disclosure process behind it — is a standard part of a website security audit. We set it up right and keep the Expires date current.