Does Your Site Need a security.txt File?

Does your marketing site need a security.txt file?

If anyone might find a vulnerability in your site or product, yes. It is a plain text file that tells a security researcher who to contact. Without one, someone who finds a problem has to guess, and guessing usually ends with a public post instead of a private email.

It takes about twenty minutes to do properly. It is one of the few things on a website where the effort and the payoff are that far apart.

The format is a real standard rather than a convention, which means there is a right way to do it and a few ways to get it wrong.

What is security.txt actually for?

It answers one question: where do I report this. Someone has found a flaw in your login flow, a misconfigured storage bucket or an exposed API key. They want to tell you. The file gives them a documented route so they do not have to hunt through your contact page.

The standard is RFC 9116, published through the IETF, so this is not a vendor format that might disappear. It defines the file location, the fields and which of them are mandatory.

The unglamorous benefit is speed. A researcher who can find your security contact in ten seconds tends to disclose privately. A researcher who spends twenty minutes failing to find one tends to lose patience, and your first notification becomes a message from a journalist.

Where exactly does the file go?

One specific path, and the spec is strict about it rather than merely suggestive. RFC 9116 states that "For web-based services, organizations MUST place the security.txt file under the /.well-known/ path, e.g., https://example.com/.well-known/security.txt." Not your site root, and not a sensible looking subfolder you chose yourself.

That matters because automated scanners look in exactly one place. A perfectly written file at the wrong path is invisible to the tools that would otherwise find it, which makes it a file you maintain for nobody.

The path also has to be served over HTTPS. The spec requires the Canonical field value to "begin with https://" and treats HTTPS as the expectation for web URIs throughout.

Which fields are required?

Two, and only two. RFC 9116 says the Contact field "MUST always be present in a security.txt file," and that the Expires field "MUST always be present and MUST NOT appear more than once." Everything else is optional, with the spec stating that "Unless otherwise stated, all fields MUST be considered optional."

Contact is what you would expect, described in the spec as "a method that researchers should use for reporting security vulnerabilities." Values "MUST follow the URI syntax," which in practice means a mailto or tel address rather than a bare email.

You can list several, and the spec says contacts "SHOULD be listed in order of preference." Put the address that a human reads first. A generic inbox nobody monitors at the top of the list defeats the purpose of the file.

Why does the Expires field matter so much?

Because a stale security contact is worse than none, and the spec builds in an expiry date to force the issue. RFC 9116 describes it as the date and time "after which the data contained in the security.txt file is considered stale and should not be used."

There is a recommended ceiling. The spec says "It is RECOMMENDED that the value of this field be less than a year into the future to avoid staleness." So you are being asked to revisit this at least annually, which is the point.

This is the field that catches teams out. We have seen files with an expiry date already in the past, which tells a researcher that nobody has looked at this in a year and probably will not read their email either. Set a calendar reminder when you publish the file.

What should you put in the optional fields?

Policy first, then Preferred-Languages, then the rest if they apply. The spec describes Policy as "a link to where the vulnerability disclosure policy is located" and notes it "can help security researchers understand the organization's vulnerability reporting practices." That link does more work than any other optional field.

Preferred-Languages "can be used to indicate a set of natural languages that are preferred when submitting security reports," and the spec notes it "MUST NOT appear more than once." Worth setting if your security inbox is read by a team in one region.

Encryption is for teams who genuinely handle encrypted reports. The spec is explicit that keys "MUST NOT appear in this field" and that the value "MUST be a URI pointing to a location where the key can be retrieved." If you would not actually decrypt a message, leave the field out.

Canonical tells a researcher where the authoritative copy lives, which matters if your file is reachable on several hostnames. The spec notes researchers "SHOULD use an additional trust mechanism such as a digital signature" to confirm a file applies, so Canonical alone is not a security control.

Can you host this on Webflow?

On the right plan, yes, and this is worth checking before you promise it to anyone. Webflow's pricing page lists a feature row called Well-known files, described as the ability to "Host files at the /.well-known/ path for domain verification and integrations." It is shown as unavailable on the lower tiers.

So on a Webflow site the question is a plan question rather than a build question. Confirm the feature is available on your site plan first, because the required path is not somewhere you can reach with a page or a redirect.

Other hosts handle this differently. On a platform where you control the deployed files, such as Vercel or Netlify, it is simply a file in your public directory. That difference is worth knowing before someone commits to a timeline.

Who actually reads it?

Independent researchers, automated scanners and, increasingly, the people running security reviews on the buying side. The first two are the reason the standard exists at all. The third is a newer benefit, and for a B2B company selling into larger organisations it may end up being the one that matters most.

Security questionnaires now routinely ask whether you have a published vulnerability disclosure route. Having one already live, at the standard path, is a faster answer than explaining your intentions. We touched on this in our notes on designing a trust centre page.

It also signals something about how you operate. A company with a current security.txt and a real policy behind it reads as a company that has thought about this. A company without one reads as a company that has not been asked yet.

What happens after someone reports something?

That is the part the file cannot solve, and the part that actually matters. Publishing a contact address creates an obligation to answer it. A researcher who emails your documented address and hears nothing for three weeks will disclose publicly, and they will be within their rights.

So decide before you publish who reads that inbox, what the acknowledgement timeline is, and who makes the call on severity. Write it down, link it from the Policy field, and keep it short enough that people follow it.

Connect it to whatever incident process you already have rather than inventing a parallel one. Our notes on planning for website incidents cover how we would wire those together.

Is it worth the twenty minutes?

Almost always. Two required fields, one fixed path, one calendar reminder a year. Against that you get a private disclosure route, a faster answer on security questionnaires, and a lower chance that your first warning about a problem is a public one.

The only case where we would hold off is if you genuinely have nobody to receive reports. In that situation the honest move is to sort out the inbox first, then publish the file, rather than advertising a route that leads nowhere.

If you want a hand putting this in place, or checking that the one you already have is still valid, we are happy to take a look. You can find us at phoenix.studio. Our broader guide to website security covers what sits around it.