security.txt
Checks whether a domain publishes security.txt (RFC 9116) — the channel to report vulnerabilities.
The domain you enter is sent to the Nexinon server at check time, used only to fetch /.well-known/security.txt (and, if missing, /security.txt as a fallback) — nothing is stored, and no other path on the site is accessed.
What security.txt is
security.txt (RFC 9116) is a standardized text file that tells security researchers how to report a vulnerability found on a site — a contact (email, form, or phone), optionally a public key to encrypt the report, and a responsible disclosure policy. Without it, a researcher who finds a flaw has to hunt down a contact channel by hand (a social media profile, a generic email, a support form), which delays or prevents a good-faith report from reaching whoever can fix it.
Where the file should live
The correct location under the RFC is /.well-known/security.txt. An old location at the site root (/security.txt) is also recognized, but the RFC itself treats it mainly as a historical redirect to the correct path — publishing only at the root, without pointing to /.well-known/security.txt, is a caveat in this check, not a failure: the file is still read, it's just not where the spec recommends.
How this tool works
The Nexinon server fetches /.well-known/security.txt on the domain you enter and, if not found, tries /security.txt as a fallback (same reason as the Security Headers Analyzer: the browser can't make this request against a third-party domain because of CORS). The content is then evaluated field by field: Contact and Expires are mandatory under the RFC (missing either one fails the verdict); Canonical, Encryption, Policy, Acknowledgments, Preferred-Languages, and Hiring are recommended and only appear in the result when the file provides them.
What this version checks
Contact: at least one occurrence, each in mailto:/https:/tel: format. Expires: exactly one occurrence, a valid date, not expired, and without a suspiciously long validity (more than 2 years triggers a warning — the RFC doesn't define an official number for this; the field exists to force periodic human review, and a validity far in the future defeats that purpose even while staying technically valid). Canonical, when present, is compared against the URL actually fetched. Encryption, when present, is recognized only by its presence — neither the link's resolution nor the file's OpenPGP signature is validated in this version (a candidate for a future version). Policy, Acknowledgments, Preferred-Languages, and Hiring are shown when present, without content validation.
Frequently asked questions
Because compliance with RFC 9116 isn't binary: a file can exist, have every mandatory field, and still deserve a warning (legacy location, wrong Content-Type, a suspiciously long validity). Reducing that to a plain yes/no would hide real information — that's why the verdict has three states: compliant, valid with caveats, or not compliant.
It isn't a security flaw by itself — it's the absence of a standardized channel for receiving vulnerability reports responsibly. Publishing one is a low-effort best practice recognized by the security community, not a legal requirement.
The field exists precisely to force periodic review: a security contact, a public key, or a policy can go stale over time even while the file stays online. A validity of decades is technically accepted by the RFC, but in practice it encourages forgetting about the file — which is why this tool warns when validity exceeds 2 years, even without that breaking the spec.
It means the file was only found at the site root (/security.txt), not at /.well-known/security.txt. RFC 9116 treats the root mainly as a historical redirect to the correct path, not as a definitive place — it works, but it's a caveat, not the ideal.
Not in this version. When the Encryption field is present, the tool only recognizes that it was provided — neither the link's resolution nor the cryptographic validity of any signature on the file is checked. That's a deeper check, a candidate for a future version.
Because fetching a file on a third-party domain from the browser runs into CORS — the same reason as the Security Headers Analyzer, SSL Checker, and Is It Down. The Nexinon server does the fetch and returns only the evaluated result; the domain you check isn't stored.
Nexinon Principles
Server
Server-side execution — data is sent to Nexinon during processingNo account needed
Use it now, no account or password.Free
No usage limits, no paid plan.Trustworthy content
Full explanation behind every tool, not just the result.