SiteSecura Logo
SiteSecura.
RFC 9116 Standards Compliance Utility

security.txt Validator

Validate your website's vulnerability disclosure contact file strictly according to RFC 9116. Verify mandatory Contact and Expires directives, inspect OpenPGP armor, and ensure ethical hackers have a safe channel to report security issues.

Strict RFC 9116 ParserMandatory Directive AuditsSafe HTTPS Socket PinningOpenPGP Armor Support
Strict HTTPS (RFC 9116)

Enter any domain or hostname. The validator will inspect RFC 9116 directives, contact links, expiration timestamps, and signature armor over secure HTTPS.

Examples:
Standardized Vulnerability Disclosure

What is security.txt & Why Does It Matter?

When independent security researchers, ethical hackers, or academic analysts discover a critical vulnerability on a website or cloud service, they frequently struggle to find an authorized contact. Security findings often end up submitted to generic support forms, spam inboxes, or sales chats, leaving vulnerabilities unpatched for months or driving researchers to publicly disclose them out of frustration.

RFC 9116 solves this communication barrier by standardizing a simple machine-readable and human-readable text file named security.txt. Hosted in a predictable well-known location, it provides clear security reporting channels, PGP public encryption keys, disclosure policy links, and hall-of-fame acknowledgments.

Without security.txt

  • Researchers submit bugs to general info@ or marketing mailboxes.
  • Critical vulnerability reports get lost in customer support queues.
  • Researchers cannot safely encrypt sensitive exploit proofs-of-concept.
  • Higher likelihood of premature public zero-day disclosure.

With a Valid security.txt

  • Direct routing to your designated security team or bug bounty platform.
  • Researchers can encrypt reports using your declared OpenPGP key.
  • Clear safe harbor guidelines established via your linked policy.
  • Automated security crawlers recognize your defensive posture immediately.
RFC 9116 Location Hierarchy

Where Must security.txt Be Hosted?

RFC 9116 Section 2.5.2 specifies a strict hierarchy of locations for serving security disclosure files. Clients and automated crawlers inspect locations in the following sequence:

Primary (Mandatory)The Well-Known Directory
https://<your-domain>/.well-known/security.txt

Defined under RFC 8615 well-known URI architecture. This location takes precedence over all others.

RFC 9116 Compliant
Legacy FallbackThe Root Directory
https://<your-domain>/security.txt

Permitted solely for backward compatibility with early drafts when the /.well-known/ path is unavailable.

Generates Warning
Field Reference

Supported RFC 9116 Directives Specification

RFC 9116 defines eight standardized directives. Every line must follow the case-insensitive format Directive: Value:

Contact

Mandatory

Direct channel for reporting vulnerabilities. Must use an absolute URI (mailto:, https:, or tel:).

Contact: mailto:security@example.com

Expires

Mandatory

RFC 3339 timestamp with timezone indicating when contact data expires. Must be in the future.

Expires: 2027-01-01T00:00:00.000Z

Encryption

Optional (0 or more)

URI pointing to an OpenPGP public key or key server used for encrypting vulnerability disclosures.

Encryption: https://example.com/pgp-key.asc

Acknowledgments

Optional (0 or more)

URL linking to your security hall of fame or vulnerability disclosure acknowledgments page.

Acknowledgments: https://example.com/hall-of-fame

Canonical

Optional (0 or more)

The authoritative HTTPS URL where this security.txt file is permanently hosted.

Canonical: https://example.com/.well-known/security.txt

Policy

Optional (0 or more)

Link to your formal Vulnerability Disclosure Policy (VDP) or safe harbor guidelines.

Policy: https://example.com/disclosure-policy.html

Preferred-Languages

Optional (0 or 1)

Comma-separated list of natural language tags (RFC 5646) preferred for security communications.

Preferred-Languages: en, de, fr

Hiring

Optional (0 or more)

Link to security job opportunities or engineering career pages for visiting researchers.

Hiring: https://example.com/jobs/security
Audit & Remediation

Top 6 Common security.txt Validation Failures

Over 40% of security.txt implementations published across the web fail RFC 9116 validation due to common syntax mistakes and stale timestamps. Here are the most frequent violations and how to fix them:

1

Missing or Expired 'Expires' Directive

Under RFC 9116 Section 2.5.5, an Expires directive is strictly mandatory. If omitted or if the timestamp is in the past, security researchers and automated scanners will classify the file as stale and invalid.

Remediation: Add 'Expires: YYYY-MM-DDTHH:MM:SSZ' with a date within 366 days in the future, and set a calendar reminder to renew it annually.
2

Missing 'Contact' Field or Invalid URI Scheme

RFC 9116 Section 2.5.3 requires at least one Contact directive using an absolute URI with a supported scheme. Plain un-prefixed email addresses or cleartext http:// links are non-compliant.

Remediation: Prefix email addresses with 'mailto:' (e.g. mailto:security@example.com) and web contact portals with secure 'https://'.
3

Hosting in Root Instead of /.well-known/

RFC 9116 Section 2.5.2 specifies https://<domain>/.well-known/security.txt as the primary standard location. Hosting only in the root directory (/security.txt) is a deprecated fallback.

Remediation: Serve the file under /.well-known/security.txt, or place an HTTP 301/308 redirect from /security.txt to /.well-known/security.txt.
4

Incorrect Content-Type Header

The file must be served with 'Content-Type: text/plain; charset=utf-8'. Serving HTML error pages (e.g. 200 OK SPA fallback) or application/octet-stream causes parser failures.

Remediation: Configure your web server (Nginx, Apache, Cloudflare) to explicitly set Content-Type to text/plain for the security.txt route.
5

Serving Over Insecure HTTP

RFC 9116 Section 2.2 strictly mandates that security.txt must be accessed using HTTPS. Cleartext HTTP allows attackers to tamper with contact addresses in transit.

Remediation: Enforce TLS/HTTPS across your website and ensure unencrypted requests automatically redirect to HTTPS.
6

Expiration Set Farther Than One Year Away

RFC 9116 Section 2.5.5 cautions against setting an expiration date more than one year in advance, because stale contact information creates serious security liabilities.

Remediation: Limit your expiration window to at most 365 days from the date of publication and integrate it into your deployment pipeline.
Production Template

Production-Ready security.txt Template

Copy and adapt this RFC 9116 compliant template for your organization. Save the file to public/.well-known/security.txt in your project repository:

# Our security contact information
Contact: mailto:security@example.com
Contact: https://example.com/security/report

# Expiration date: RFC 3339 format (maximum 1 year ahead)
Expires: 2027-01-01T00:00:00.000Z

# Public PGP Key for encrypted disclosures
Encryption: https://example.com/.well-known/pgp-key.asc

# Vulnerability disclosure policy and safe harbor
Policy: https://example.com/security/policy

# Security hall of fame / bug bounty acknowledgments
Acknowledgments: https://example.com/security/hall-of-fame

# Canonical location of this file
Canonical: https://example.com/.well-known/security.txt

# Preferred communication languages (RFC 5646)
Preferred-Languages: en, de

# Career opportunities for security researchers
Hiring: https://example.com/careers/security
Frequently Asked Questions

security.txt Validator FAQs

Answers to common technical questions about RFC 9116 validation, directive requirements, and disclosure policies.

security.txt is an established Internet standard (RFC 9116) that defines a standard text file format and location for organizations to publish their security contact details, vulnerability disclosure policy, and encryption keys. It solves the critical problem where ethical security researchers find a vulnerability on a website or API but cannot determine how or to whom to safely report it.
Defensive Utilities

Explore Companion Security Tools

Check other aspects of your defensive perimeter with our standalone diagnostic utilities.

DNS Records

DNS Lookup Tool

Inspect A, AAAA, CNAME, MX, NS, TXT, SOA, and CAA records without launching a full perimeter scan.

Launch Utility
HTTP Utility

HTTP Status & Redirect Checker

Inspect HTTP status codes, trace 301/302 redirect chains hop-by-hop, and detect SSL downgrade vulnerabilities.

Launch Utility
HTTP Headers

HTTP Security Headers Checker

Analyze HSTS, Content-Security-Policy, X-Frame-Options, and defensive browser headers.

Launch Utility
SSL / TLS

SSL/TLS Certificate Checker

Verify certificate expiration dates, cipher suite strength, and certificate authority trust chains.

Launch Utility
Email Security

SPF, DKIM & DMARC Checker

Review email authentication DNS records to protect domain reputation and prevent phishing attacks.

Launch Utility
Full Perimeter Scan

Instant Website Security Scanner

Run an automated multi-vector security assessment across DNS, SSL, HTTP headers, ports, and disclosure.

Launch Utility
Full Defensive Posture Assessment

Ready to Secure Your Entire Website Perimeter?

Don't stop at security disclosure files. SiteSecura evaluates SSL/TLS certificates, HTTP security headers, DNS configurations, exposed administration panels, and open attack vectors in seconds.

Run Free Perimeter ScanBrowse All Defensive Tools