News
security.txt vs a Public /security Contact Page
September 24, 2025
security.txt vs a public /security contact page is a channel split, not a lock. RFC 9116 security.txt lives at https://example.com/.well-known/security.txt and tells researchers where to send a report (Contact, Expires, Preferred-Languages, optional Policy and Canonical). A /security or /responsible-disclosure HTML page is for humans and legal tone. You usually want both: the file for tools and the page for people. Neither authenticates anyone or hides /.env. RoastMyOpsec is a consent-based roast of URLs you assert you own. It does not require security.txt, does not file bugs for you, and does not scan third-party sites as 'research.'
The practical difference
security.txt is a small, signed-optional text file at a well-known path. Parsers look there first. Expires is required so stale mailboxes do not become a sink. Contact should be a mailbox or URL you actually monitor — not a 404.
A public security page is narrative: scope, safe harbor language your counsel approved, and what you will not pay for. It will not be found by every scanner unless you also ship security.txt or link it from the footer.
How to choose what to publish
If you have no intake mailbox, do not publish a Contact you will ignore. Stand up an alias, then add security.txt with a near-term Expires you will renew. If legal needs a policy URL, add Policy: and keep the HTML page in sync. Do not list a personal Gmail you will abandon.
If you run a bug bounty, point Policy or Contact at the program, not a generic info@ that auto-replies 'we do not accept unsolicited reports' while the file still invites them.
| Channel | Audience | What it is not | Takeaway |
|---|---|---|---|
| /.well-known/security.txt | Tools and researchers who know RFC 9116 | Access control; a pentest letter | Publish if you will actually read Contact |
| /security HTML | Humans, counsel, procurement | A substitute for the well-known path | Keep policy language here; link both ways |
| robots.txt Disallow | Crawlers | A disclosure inbox | See robots vs access control |
| RoastMyOpsec roast | You, on a URL you own | A researcher filing a CVE | Self-audit; still publish a real Contact |
What this has to do with OPSEC
A missing security.txt is not a vulnerability. A Contact that bounces, or a file that advertises a dead Slack webhook, is an OPSEC miss: good-faith reports go to /dev/null while the same bugs stay public. Do not put secrets, VPN hostnames, or internal Jira in the file.
The roast may probe well-known sensitive paths for signatures. security.txt is a disclosure aid, not one of those leak classes. Presence is optional; honesty of Contact is not.
Common mistakes
The first mistake is security.txt at the site root only, skipping /.well-known/security.txt.
The second mistake is an expired Expires and a Contact nobody owns.
The third mistake is using the file to 'invite' scans of hosts you do not control.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Do I need security.txt to pass a RoastMyOpsec scan?
- No. The roast is a consented public-surface audit. security.txt is for humans and tools that want to report issues. It is not a scoring gate.
- Is a /security page enough without security.txt?
- It is enough for visitors who click it. Researchers who look up RFC 9116 will miss you. Ship both if you want reports.
- Should I list my production admin URL in security.txt?
- No. Publish a contact and a policy. Do not donate inventory. See admin discoverability vs access control.