Is security.txt required?

Not legally, but it is an RFC-track standard and is increasingly expected in vendor security questionnaires and bug-bounty triage. It costs one file to publish.

Why is the Expires field mandatory?

So consumers can tell a maintained file from an abandoned one. RFC 9116 requires exactly one Expires value, and a file past that date should be treated as untrustworthy.

Where exactly should the file live?

At https://example.com/.well-known/security.txt, served as text/plain over HTTPS. The root-level location is legacy and should redirect to the well-known path.

Can I list multiple contacts?

Yes. Multiple Contact fields are allowed and are interpreted in order of preference, so put the monitored inbox first.

Security🌐 YAS server-sideAPI availableintermediate

security.txt RFC 9116 Validator

Validates web security.txt policy files against the IETF RFC 9116 specification.

Processed by YAS · not stored

Ready to runInstant execution

All tools →

Result

—

What does this tool do?

Validates web security.txt policy files against the IETF RFC 9116 specification.

Why would I use it?

You want security researchers and ethical hackers to responsibly disclose vulnerabilities to your team.
You are auditing your domain compliance against enterprise security standards.
You need to verify that mandatory fields (Contact, Expires) are formatted correctly.

Real-life example

Input

Contact: mailto:security@example.com\nExpires: 2027-01-01T00:00:00.000Z

Output

Status: VALID RFC 9116 · Contact Directives: 1 · Expiration: in 137 days

Requires RFC 3339 timestamp format for Expires.

Input → Process → Output → Next

Input: Paste security.txt text or fetch from your domain's /.well-known/security.txt.
Process: Parses directives, verifies mandatory fields, checks URI schemes, and evaluates expiration.
Output: Compliance audit report with errors, warnings, and parsed directives.
Next action: Deploy the file at https://yourdomain.com/.well-known/security.txt.

Common mistakes

Deploying security.txt over plain HTTP instead of HTTPS.
Setting an expiration date in the past (immediately invalidates the file).
Missing the Contact: directive with mailto: or https: scheme.

What the result means

Verification that your organization's vulnerability disclosure policy meets international standards.

Privacy & security

Your input is sent to YAS infrastructure because the tool requires server-side processing or public network queries. Input is not stored.

API

Endpoint

POST https://yas.sh/api/v1/tools/security-txt-validator

Request Header

Content-Type: application/json

cURL

curl -X POST "https://yas.sh/api/v1/tools/security-txt-validator" \
  -H "Content-Type: application/json" \
  -d '{"input":"Contact: mailto:security@example.com\nExpires: 2027-01-01T00:00:00Z"}'

JavaScript

const res = await fetch("https://yas.sh/api/v1/tools/security-txt-validator", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
  "input": "Contact: mailto:security@example.com\nExpires: 2027-01-01T00:00:00Z"
}),
});
const data = await res.json();

Python

import requests

r = requests.post("https://yas.sh/api/v1/tools/security-txt-validator", json={"input":"Contact: mailto:security@example.com\nExpires: 2027-01-01T00:00:00Z"})
data = r.json()

Field	Type	Required	Description
input	string	Yes	security.txt content

Success response

{ "slug": "security-txt-validator", "valid": true, "totalDirectives": 2 }

Validate RFC 9116 security.txt files for contact and expiration.

Error responses

400 VALIDATION_ERROR — invalid input or unsupported option.
413 PAYLOAD_TOO_LARGE — input exceeds the 64 KB limit.
429 RATE_LIMIT_EXCEEDED — rate limit exceeded (60 req/min).

Limits

Maximum input: 64 KB per request.
Rate limit: 60 requests/min per IP address.
Authenticated accounts benefit from higher tier quotas.

How security.txt RFC 9116 Validator works

RFC 9116 defines a plain-text file at /.well-known/security.txt listing how to report a vulnerability. The parser checks the required fields — at least one Contact and exactly one Expires — plus optional Encryption, Acknowledgments, Preferred-Languages, Canonical, Policy and Hiring fields. Expires must be an ISO 8601 timestamp in the future; a past date means the file is formally stale and should not be trusted.

The specification is strict in ways that trip people up. Field names are case-insensitive but values are not, Contact values must be URIs (mailto:, tel: or https:), the file must be served over HTTPS with a text/plain content type, and if the file is signed the Canonical field must match the URL it is served from.

When to use it: real-world scenarios

Publishing a disclosure channel before you need one

Researchers who cannot find a contact either post publicly or move on. A valid security.txt is the cheapest incident-preparedness step available.

Checking a vendor's file before reporting a finding

Confirming the contact and preferred languages before writing a report avoids sending sensitive details to an unmonitored address.

Auditing a fleet of domains

Organisations with many properties routinely have a valid file on the flagship domain and nothing anywhere else.

Catching an expired file

The Expires field exists so stale files are detectable. Validating on a schedule is how you notice before a researcher does.

Pro tips

Set Expires no more than a year out and add a calendar reminder. An expired file signals an unmaintained programme.
Use a role address (security@) that reaches a monitored inbox, never an individual — people change roles, vulnerabilities do not wait.
Serve the file at /.well-known/security.txt. The legacy root location is permitted only as a redirect target and should not be primary.
Add Policy pointing at your disclosure terms and Preferred-Languages if your team is not English-first; both measurably improve report quality.

Limitations and edge cases

What this tool deliberately does not do, and where it will disagree with other implementations.

Syntax and field validation only — the tool cannot verify that the contact address is monitored or that reports get answered.
PGP signature verification of a signed file is not performed.
A file that fails to fetch may be blocked by a WAF or CDN rather than genuinely absent.
Presence of a valid file says nothing about the quality of the security programme behind it.

Frequently asked questions

Is security.txt required?: Not legally, but it is an RFC-track standard and is increasingly expected in vendor security questionnaires and bug-bounty triage. It costs one file to publish.
Why is the Expires field mandatory?: So consumers can tell a maintained file from an abandoned one. RFC 9116 requires exactly one Expires value, and a file past that date should be treated as untrustworthy.
Where exactly should the file live?: At https://example.com/.well-known/security.txt, served as text/plain over HTTPS. The root-level location is legacy and should redirect to the well-known path.
Can I list multiple contacts?: Yes. Multiple Contact fields are allowed and are interpreted in order of preference, so put the monitored inbox first.