In one paragraph
A missing security.txt means the scan did not find the expected disclosure contact at /.well-known/security.txt. Publish a valid plain-text file with a monitored Contact URI and a future Expires value, then verify the deployed response. The file helps researchers report problems; it does not fix vulnerabilities, promise a bounty, or replace the team's process for handling reports.
Why it matters
Researchers who find a problem need a reliable private reporting channel. A fixed machine-readable location reduces guesswork and can direct reports away from sales forms or public social posts. RFC 9116 defines the format and well-known location.
The useful work is both publication and ownership. A valid-looking address nobody monitors can leave a reporter believing the organisation has been notified when nobody has triaged the issue. Establish who responds and how credible findings are escalated.
Publishing this file does not itself authorise testing, establish legal safe harbour, or create a payment commitment. State any testing scope or disclosure terms clearly in an appropriate policy and review applicable obligations separately. Do not infer universal legal requirements from an informational scanner result.
How WebAuditOS evaluates this finding
The supplied probe requests /.well-known/security.txt on the scanned origin and follows redirects. A 200 body containing Contact: passes. A missing file or a 200 body without that text warns informationally; the documented authentication, rate-limit, server-error, timeout, and unavailable cases can remain ungraded.
The text match is much narrower than RFC validation. An expired file or HTML catch-all containing Contact: can pass. The probe does not verify Expires, content type, usable URIs, scope, or signature. A legacy /security.txt location is not queried directly by this rule.
How to fix it
- Establish a monitored reporting channel and an owner. Decide how reports are acknowledged, investigated, and escalated. Avoid publishing an inbox that is about to be retired or requires the researcher to hold a customer account.
- Create a UTF-8 plain-text file with the required Contact and Expires fields. An illustrative example is:
Contact: mailto:[email protected]
Expires: 2027-04-21T00:00:00Z
Preferred-Languages: en
Policy: https://example.com/security/disclosure
Canonical: https://example.com/.well-known/security.txtReplace every example address and URL. Choose a genuinely maintained future expiry date; RFC 9116 recommends less than a year ahead. The sample is not a permanent date to reuse indefinitely.
- Use URI syntax for contacts. Email requires mailto:, a phone contact uses tel:, and web contacts use HTTPS. Include optional fields only when their targets exist and their meaning is understood.
- Serve the file over HTTPS at the well-known path with an appropriate text/plain content type. Put it in the static public directory or an exact route, checking that build tools do not omit the dot-prefixed folder. A legacy top-level copy can redirect appropriately, but the well-known URL must work.
- Verify hosts separately. A file on the apex is not automatically a declaration for every subdomain. If redirecting to a central file, review RFC scope and canonical handling rather than assuming one contact endpoint covers every origin automatically.
- Request the public URL outside your authenticated browser session. Check status, final URL, content type, actual file contents, and the real expiry. Also request an unrelated missing path to detect a universal HTML catch-all.
- Schedule review before expiry and when ownership changes. Test the contact channel and policy links, then rescan. Validate the RFC requirements independently of the scanner's limited Contact: test.
What the fix can break
The main operational cost is incoming reports, including duplicate or low-quality automated findings. Establish triage without implying that every report earns compensation.
A stale contact, expired file, or inaccessible policy can defeat the purpose while still passing a simple probe. Monitor the file and channel independently.
Do not place secrets, private escalation details, or credentials in a public disclosure file. Optional cryptographic signing is a separate integrity measure and requires a maintained verification process; a signature is not a reason to skip basic HTTPS and expiry checks.
Questions
Are Contact and Expires both required?
Yes, RFC 9116 requires both. The documented WebAuditOS presence test checks only Contact text, so validate the remaining requirements separately.
Does the file authorise penetration testing?
Not by itself. Define any permitted activity and reporting terms in the relevant policy rather than assuming the format grants permission.
Why can an expired file pass?
The supplied scanner does not parse and validate the expiry field. Its pass is not equivalent to full RFC compliance.
Which related pages help?
Review a security page or trust center and the security headers guide.