Does Your Site Publish a security.txt File?

A security.txt file is a small, plain-text document that tells security researchers how to report a vulnerability they find on your site or app backend. When someone discovers a bug, they should not have to guess at admin@, dig through your privacy policy, or post the issue publicly because they could not reach you. A standardized file at a predictable path solves that. For an indie developer or store owner about to launch, it is a low-effort signal that you have thought about responsible disclosure before the first researcher comes knocking.

The format is defined by RFC 9116. LaunchTrust treats the presence of a valid security.txt as a positive signal: something you generally want present, not a risk whose presence is the problem. Its absence is not a blocking issue for most app stores, but it is a recognized security best practice and an easy win to publish before submission.

What LaunchTrust checks

The security_txt detector inspects your public web origin only. It does not log in, crawl deeply, or judge whether your disclosure process actually works. Specifically, it:

1. Derives the origin from the page it scanned (the final URL after redirects).
2. Requests two well-known locations in order: /.well-known/security.txt (the canonical RFC 9116 path) and the legacy /security.txt at the site root.
3. Requires an HTTP 200 OK response, then reads the body and looks for a Contact: line (case-insensitive).
4. If a Contact: line is present, it also checks for an Expires: field and whether that date is still in the future.

The result maps to one of three signals:

• Detected — a reachable file contained a Contact: field. If an Expires: date is present and still valid, the signal is reported at an informational level ("Expires valid"). If Expires: is missing or already past, it is still detected but flagged at a low level ("Expires stale" or "no Expires field"), because RFC 9116 expects a current expiry date.
• Not detected — neither path returned a 200 response with a Contact: field. RFC 9116 is an optional best practice, so this is reported at a low level, not as a failure.
• Unable to determine — the scanner could not derive a usable origin from the target.

This is signal reporting, not a verdict. "Detected" confirms a published file exists and is shaped correctly; it does not certify that the contact address is monitored.

Why it matters

security.txt is described in RFC 9116, "A File Format to Aid in Security Vulnerability Disclosure." It is not a law and no app store mandates it, but it is widely adopted across the security community and is one of the first things a researcher or automated scanner looks for. Publishing one:

• Gives security researchers a clear, machine-readable contact path, which reduces the chance of a vulnerability being disclosed publicly or sold instead of reported to you.
• Pairs naturally with other trust signals reviewers and partners look for, such as a reachable contact or imprint and sound transport security.
• Signals operational maturity to anyone doing due diligence on your launch, including review teams and enterprise buyers.

It complements, rather than replaces, the human contact details you publish elsewhere on the site.

A concrete example

A minimal RFC 9116 file served at https://yourdomain.com/.well-known/security.txt looks like this:

Contact: mailto:security@yourdomain.com
Contact: https://yourdomain.com/security/report
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: en
Canonical: https://yourdomain.com/.well-known/security.txt

Only Contact: and Expires: are required by the spec. The detector keys on Contact: for the "detected" signal and reads Expires: to judge freshness. Set Expires: to a date you will actually revisit — a year out is common — so the file does not silently go stale.

How to address it

1. Pick a reliable contact channel, such as a monitored security@ inbox or a dedicated reporting URL. Avoid a personal address that may change.
2. Create a plain-text file named security.txt with at least a Contact: line and an Expires: line set to a future date in ISO 8601 format.
3. Serve it at /.well-known/security.txt. Add the root /security.txt as a fallback if your host makes it easy, but the well-known path is the canonical one.
4. Confirm it returns HTTP 200 with Content-Type: text/plain and is not behind authentication, a redirect to your SPA, or a catch-all index.html.
5. Add a calendar reminder to refresh the Expires: date before it lapses, and update contacts if your team changes.
6. Optionally sign the file with PGP and reference the signature, as RFC 9116 allows, for higher-assurance setups.

Check this in 30 seconds

Run your domain through the free LaunchTrust scanner. It fetches both well-known paths, tells you whether a Contact: field was detected, and flags a missing or stale Expires: date — so you know exactly what to publish before you submit. You get the specific signal back in seconds, with no account required for a basic scan.

FAQ

Is a security.txt file legally required? No. RFC 9116 is a voluntary best practice, not a regulation, and no major app store requires it. It is strongly recommended because it gives researchers a clear way to reach you, but its absence will not, by itself, block a store submission.

Where should the file live? The canonical location is /.well-known/security.txt at your domain root. A copy at /security.txt works as a legacy fallback. LaunchTrust checks both and reports "detected" if either returns a valid file.

Why does LaunchTrust flag my Expires date? RFC 9116 expects an Expires: field with a future date so consumers know the file is current. If yours is missing or already past, the detector still reports the file as detected, but at a lower-confidence level, prompting you to refresh it.

Does publishing security.txt satisfy app store or legal requirements? No. The detector surfaces a signal — whether a correctly shaped security.txt file is published — and nothing more. It is not legal advice, it does not certify your security posture, and a "detected" result is not a guarantee of approval. Treat it as one input among many.

Compliance aid, not legal advice. LaunchTrust reports signals, not a verdict or certification.