Domain.Posture

security.txt checker

check whether a domain publishes a security.txt (RFC 9116) at /.well-known/security.txt — the standard channel for reporting vulnerabilities. part of the domainposture.com domain dossier.

security-txt

info
Open standalone →

checking security.txt…

Want every check for composio.dev on one page? Open the full dossier →

Overview

security.txt (RFC 9116, published 2022) standardises how a security researcher finds out where to report a vulnerability. before it existed, a researcher who found a bug had to guess — try security@, try support@, search for a bug-bounty page, or give up and post publicly. RFC 9116 fixes this with one predictable location: `https://<domain>/.well-known/security.txt`, a plain-text file with a small set of defined fields. the two that matter most are `Contact:` (one or more ways to reach the security team — a mailto: address, an https: reporting form, or both) and `Expires:` (a required-in-spirit freshness date so researchers know the file hasn't gone stale). optional fields include `Encryption:` (a PGP key for sensitive reports), `Preferred-Languages:`, `Canonical:`, and `Policy:` (a link to a full disclosure policy or bug-bounty program). this tool fetches the file, rejects HTML catch-all responses the same way the llms.txt checker does, and requires at least one `Contact:` field before reporting the file as present. absence is the one finding in this trio of checks that carries real audit weight: a security review expects a published disclosure channel, and its absence means a researcher who finds an issue has no sanctioned way to report it — reports get dropped, delayed, or go straight to public disclosure.

How to use

  1. enter a bare domain — public fqdn only. no scheme, no port.
  2. fetch security.txt — the tool requests https://<domain>/.well-known/security.txt, rejects HTML catch-all responses, and requires at least one Contact: field before treating the file as valid.
  3. read the contact and expiry — when present, the tool lists every Contact: value (mailto: or https: reporting routes) and the Expires: date if one was set.

Examples

example 1 — a valid file needs at least one Contact: line — Expires: is optional but recommended.
input
site with a valid security.txt
output
contact: [mailto:[email protected]] · expires: 2027-01-01T00:00:00.000Z
example 2 — graded low: a security audit expects a published disclosure route, so absence is the one real advisory this trio adds.
input
domain with no security.txt
output
not_applicable — no security.txt (http 404)

Common mistakes

  • it must be at /.well-known/, not the domain root — RFC 9116 defines the canonical location as `/.well-known/security.txt`. a copy at `/security.txt` (the root) is permitted as a legacy fallback but the well-known path is what compliant tools and researchers check first — publish both if in doubt.
  • a missing Contact: field makes the whole file invalid — RFC 9116 requires at least one Contact: line. a security.txt with only a Policy: or Encryption: field and no Contact: doesn't tell a researcher how to reach anyone — this tool treats that as equivalent to no file at all.
  • an expired file signals neglect, not just missing metadata — the Expires: field exists so automated tools and researchers can tell whether the file is stale. an Expires: date in the past suggests the security contact hasn't been reviewed recently — treat it the way you'd treat an expired TLS certificate.
  • this is the one check in the AI/content-posture trio that can lower a grade — ai-crawler policy and llms.txt are informational — a stance, not a finding. security.txt absence is graded low because, unlike the other two, a published vulnerability-disclosure channel is a baseline expectation in a security review.

FAQ

what is security.txt?

a plain-text file at /.well-known/security.txt (RFC 9116) that tells security researchers how to report a vulnerability — at minimum, a Contact: field with an email or reporting-form URL.

why does a missing security.txt lower the grade?

a published disclosure channel is a baseline expectation in a security audit. without one, a researcher who finds a real issue has no sanctioned way to report it, so reports get dropped, delayed, or published without warning.

what should the Contact: field contain?

a mailto: address monitored by a security team, an https: URL to a reporting form or bug-bounty page, or both. avoid a generic support@ inbox that isn't triaged for security reports.

do I need a PGP key in my security.txt?

no — the Encryption: field is optional. it's useful if researchers might need to send sensitive proof-of-concept details, but a Contact: field alone satisfies RFC 9116.

can ai agents call this?

yes — dossier_security_txt on the mcp endpoint at domainposture.com/mcp/mcp.

how do I publish a security.txt?

create a plain-text file at /.well-known/security.txt with at minimum a Contact: line (mailto: or https:), add an Expires: date so it doesn't go stale, and optionally a Policy: link and an Encryption: key. serve it as text/plain, not HTML.

Related tools

  • ai-crawler checker — see whether a domain's robots.txt has declared a stance for GPTBot, ClaudeBot, and other major AI crawlers.
  • llms.txt checker — check whether a domain publishes an llms.txt content index for AI agents.
  • web surface inspector — fetch robots.txt, sitemap.xml, and the home page's <head> to summarise a domain's public-web surface.

References

  1. RFC 9116 — A File Format to Aid in Security Vulnerability Disclosure
  2. securitytxt.org

Free beta

Unlock your full scan (free beta)

Add one DNS TXT record to prove you own the domain, then we run a deeper active scan — exposed secrets and config — and send you a private report. Free beta, no payment.

  • Finds exposed .env / .git / backups and other sensitive files
  • Verified by a DNS TXT record, so only you can run it on your domain
  • A private report emailed straight to you
Unlock full scan