ZeroTrace OSINT
security.txt
Parsed RFC 9116 fields, PGP key fetch, expiry status, and bulk apex / www probing.
security.txt is the IETF-standardised file (RFC 9116) at /.well-known/security.txt that publishes a site's security-contact information. The tool fetches and parses this file, validates expiry, and optionally fetches and fingerprints the PGP key.
For responsible disclosure, vendor due diligence, and finding-an-authorised-contact-quickly scenarios, this is the right first stop.
What you get
| Field | What it tells you |
|---|---|
| Contact | Email, phone, or URL the operator publishes for security reports |
| Encryption | URL of a PGP key for encrypting reports |
| Expires | Date the security.txt is valid until — must not be in the past |
| Acknowledgments | URL of a hall-of-fame for past reports |
| Preferred-Languages | Languages the security team accepts reports in |
| Canonical | The URL where security.txt should be authoritative |
| Policy | URL of the operator's full vulnerability-disclosure policy |
| Hiring | URL of security-related job openings (often used to seed recruiting outreach) |
All fields are parsed per RFC 9116. Multi-value fields (multiple Contact lines, etc.) are preserved.
Expiry validation
The Expires field is mandatory in RFC 9116. The tool surfaces the expiry status as a freshness chip:
| Status | Meaning |
|---|---|
| Valid (more than 30 days remaining) | The contact is fresh. |
| Expiring soon (less than 30 days) | Contact may go stale — note this if you are filing a report. |
| Expired | The contact may no longer be monitored. The operator is technically out of compliance with RFC 9116. |
An expired security.txt is a finding in itself for vendor-due-diligence work — it suggests the security-disclosure programme is not actively maintained.
PGP key fetch
If the file lists an Encryption URL, the tool fetches the key file and surfaces:
- Key fingerprint.
- Algorithm and key size.
- User IDs.
- Subkeys.
- Validity dates.
This lets you confirm that the published key matches the operator's public-keyserver entry — a useful authentication step if you are about to send a sensitive vulnerability report.
A surprising number of security.txt files publish PGP keys that are expired, revoked, or do not match the published fingerprint. The fetch-and-fingerprint check is worth running before you encrypt anything.
Bulk apex + www probing
Sites publish security.txt at the apex (example.com/.well-known/security.txt) or at www.example.com. The tool checks both automatically and merges the results.
For a list of domains, bulk paste runs the same probe against each and aggregates the result — a fast way to find which vendors actually publish a security.txt, and which do not.
Canonical-URL HTTPS check
If the file lists Canonical URLs, the tool checks whether each canonical URL is HTTPS-reachable and whether the served content matches what was just fetched. A canonical URL that 404s (or serves a different security.txt) is a misconfiguration worth noting.
Pivots
| Click on... | Pivot to |
|---|---|
| Contact email | Email analyzer |
| Contact phone | Phone lookup |
| Contact URL | Site analysis, Wayback, redirect analyzer |
| Encryption URL | URL parser |
| Acknowledgments / Policy URL | Site analysis |
| Canonical URL | URL parser |
When the file does not exist
A site without a security.txt is the common case (most websites do not publish one). The tool returns a structured "not found" with the URLs it tried. For an authorised security report against such a site, the WHOIS lookup's abuse contact and the ASN lookup's abuse contact are the next-best fallbacks.
Sources
- Direct HTTP fetches against
<host>/.well-known/security.txt. - A direct fetch of the published Encryption URL when present.
- Direct probes against listed Canonical URLs when present.