The short answer
On a standard Shopify store you cannot publish a security.txt file at the location the spec requires.
The path /.well-known/ is routable by Shopify, meaning Shopify itself can serve things there, but it is not writable by merchants. There is no file manager, no theme asset, and no setting that puts a file at that path. Every store we tested returns a 404.
If you came here looking for a fix, we are sorry. There genuinely is not one.
Why the obvious workarounds do not work
Three ideas come up repeatedly. Here is where each one lands.
- →An app proxy. This is the closest thing Shopify has to custom routing, and it cannot reach here. The proxy prefix is restricted to a, apps, community and tools. .well-known is not on that list and cannot be chosen.
- →A theme page. You can make a page whose content is your security.txt text. It will not count. RFC 9116 requires Content-Type: text/plain; charset=utf-8, and a CMS page is served as text/html. That is a spec violation, not a technicality a scanner will let slide.
- →A URL redirect from /.well-known/security.txt. Reports from the community conflict on whether this even works, so we are not going to tell you it does. More importantly, see below: it would not fully satisfy the spec even if it did.
Why even a working redirect would not count
This part is worth understanding, because it is the reason we stopped chasing it.
RFC 9116 does sanction redirects, but only in one direction: from the legacy top-level /security.txt to /.well-known/security.txt. That is the migration path for sites that published at the old location years ago.
It does not sanction the reverse. Redirecting away from /.well-known/security.txt to somewhere else is not what the spec describes. So even if Shopify allowed the redirect, and even if it fired reliably, you would be pointing at a file that is still not where the spec says it must be, still not served as text/plain.
That is a lot of effort to fail the same check slightly differently.
What the spec actually requires
For context, so you know what you are up against. RFC 9116 says the file must be at /.well-known/security.txt, must be served over https, and must have a content type of text/plain; charset=utf-8. Two fields are mandatory:
Mandatory. The spec says this field must always be present. It is how a researcher reaches you, so it is the whole point of the file.
Mandatory. Must always be present and must not appear more than once. Recommended to be less than a year out, which means the file needs maintenance. An expired security.txt is itself a finding.
What a valid file looks like
For reference, and for the day you are on a platform that lets you serve it. This is a complete, valid minimal file:
Contact: mailto:[email protected]
Expires: 2027-01-01T00:00:00.000ZKeep this for later. You cannot serve it from a standard Shopify store today. Note the Expires date needs updating before it passes, since the spec recommends under a year.
What to do instead
Strip away the file format and security.txt is answering one question: if someone finds a vulnerability in your store, how do they tell you? You can answer that question without the file.
Publish a security contact page. Make a normal Shopify page at something like /pages/security. Put a real, monitored email address on it. Say briefly that you welcome reports and roughly how you respond. Link it from your footer so it is findable in one click, not three.
It will not pass an automated security.txt check. A human researcher who wants to reach you will find it, and that is the outcome the file exists to produce.
Use a real address. A security@ alias that lands in a monitored inbox beats a contact form nobody reads. Reports get abandoned when the first message bounces.
Do not let this one bother you
Some checks are worth chasing. This one is not, on Shopify.
A missing security.txt on a small store is a low-severity finding. It is a discoverability convenience for researchers, not a hole an attacker walks through. There is no version of this where a shopper is harmed because your store lacks a text file.
Spend the effort where you still have control. Your SPF and DMARC records live in DNS, so Shopify is not standing in your way there, and they stop people sending fake email in your store's name. That is a real attack on a real store. This is a 404 on a text file.
If you want to see where you actually stand, run a free check, or browse the full fix-it matrix to see which checks are winnable on your platform.
Run your site through our free safety check to confirm the fix is live, and see what else a shopper would notice.
Run a free checkFrequently asked questions
Can I add security.txt to a Shopify store?
Not on a standard store. The /.well-known/ path is routable by Shopify but not writable by merchants, and every store we tested returns a 404 there. There is no theme setting, app or file manager that changes this.
Can an app proxy serve security.txt?
No. Shopify restricts the app proxy prefix to a, apps, community and tools. You cannot choose .well-known, so the proxy cannot reach the path the spec requires.
Can I redirect /.well-known/security.txt to a page?
Community reports conflict on whether Shopify allows that redirect, so we will not promise it works. Even if it did, it would not fully satisfy RFC 9116. The spec sanctions redirects from the legacy /security.txt to /.well-known/, not the reverse, and a CMS page is served as text/html rather than the required text/plain.
What fields does security.txt require?
Contact and Expires are both mandatory under RFC 9116. Contact must always be present. Expires must always be present and must not appear more than once, and is recommended to be less than a year in the future, so the file needs periodic renewal. An expired file is itself a finding.
Will failing this check hurt my store?
Very little. A missing security.txt is a low-severity, discoverability finding, not an exploitable weakness. It is not winnable on Shopify today, so publish a clearly linked security contact page with a monitored address instead and put your effort into checks you can actually pass.