Build files that test RFC 9116 handling
Can researchers reach you about a vulnerability? One fetch shows your security.txt as they read it.
Build or paste authorized security.txt fixtures to exercise contact, expiry, canonical URL, media type and publishing failures, then review a corrected draft. Jump to: What does it mean?, How to fix it, Break it, Ask your agent.
Live default
Pasted files stay in your browser. A pasted or dropped security.txt is read here and never uploaded.
A host name means one fetch from our server. It requests /.well-known/security.txt over HTTPS, follows up to five HTTPS redirects and keeps nothing.
Findings
What a researcher sees
Expiry
The file as served
Write a security.txt
Corrected security.txt
Take it further
What this result means
Written for this result.
The security.txt published for google.com was checked against RFC 9116. Checked with Tamperbox by fetching https://google.com/.well-known/security.txt. What should a yearly review of a security.txt file cover, and how far ahead should its Expires date be set? The check came from Tamperbox /security-txt-checker. Its method and limits are at https://tamperbox.dev/security-txt-checker.md; read them before relying on the result.
Connect Tamperbox MCP and the agent can run this check itself, with the same limits.
The page rewrites this card with the file as it is served when the page opens, so what it says follows that file, not this text.
- Serve it at /.well-known/security.txt as text/plain; charset=utf-8, over HTTPS.
- Review it yearly, when you move the Expires date.
Repairs never change the site: they load a corrected copy here, for you to publish.
Validity here means RFC 9116 syntax and rules. Whether anyone reads the Contact mailbox is something only a real report can tell.
Nothing you enter is stored.
How it works
Enter a host name and our server requests https://host/.well-known/security.txt once, follows up to five HTTPS redirects and reads at most 64 KiB; paste a file and it is read in your browser. The file is checked against RFC 9116 and shown the way a researcher reads it: where to report, which key and policy apply, and when it expires, with problem lines marked and a corrected file to publish.
The full method, every rule and worked examples are on docs.tamperbox.dev.
Limits and interpretation
Only /.well-known/security.txt is requested, not the legacy /security.txt location. A PGP signature is recognised and separated from the file, but not verified. A valid file shows that the format is right; it does not show that anyone reads the Contact mailbox, who controls it, or that testing is permitted. A missing Expires, an expired date, an http:// web address or a Canonical that names another address makes the file invalid; an Expires more than a year ahead is only a recommendation. A pasted file has no media type, redirects or fetch address, so those checks need a live lookup. The live default is fetched when the page opens and its findings can change when the site edits its file. Nothing is stored.
Frequently asked questions
Where should security.txt be published?
At https://your-host/.well-known/security.txt, served as text/plain; charset=utf-8. This checker requests only that location and reports its status, media type and content.
Why is an Expires date years ahead only a warning?
RFC 9116 requires an Expires field and recommends a date less than a year ahead, so a later date is valid but lets stale contacts survive unnoticed. An Expires in the past makes the file invalid.
Does a valid security.txt authorize penetration testing?
No. It provides contact and policy information. Read the linked policy and obtain any required authorization separately.
References
security.txt: RFC 9116, section 2 for fields and section 3 for location · Date and time format: RFC 3339, section 5.6 · Language tags: RFC 5646 · OpenPGP cleartext signatures: RFC 9580, section 7.
Are you an AI agent? You are in the right place.
This page and every tool are available as plain text with their methods and limits, and the same checks run over MCP.