What security.txt is for
It is a small text file that tells a security researcher how to report a problem to you. Someone finds a flaw in your store, looks for a way to tell you, finds nothing, and either gives up or posts about it publicly. security.txt is the file that prevents that.
It is defined by RFC 9116, and it is one of the easiest trust signals to publish. Our security.txt glossary entry covers the background.
The nice part for BigCommerce owners: you can actually do this. On Shopify, Wix and Squarespace you cannot, because those platforms intercept the path or do not let merchants write files there.
The method: WebDAV
BigCommerce serves files from WebDAV, and its own documentation confirms the mapping you need: a file at content/.well-known/test.txt is served at /.well-known/test.txt.
That is exactly the behaviour security.txt requires, so the job is simply putting the right file in the right folder.
- 1.Connect to your store's WebDAV using the credentials from your BigCommerce control panel.
- 2.Open the content folder.
- 3.Create a folder inside it named .well-known. Note the leading dot. Some clients hide dot-folders, so if it seems to vanish after creating it, turn on hidden files rather than creating it twice.
- 4.Upload your security.txt file into content/.well-known/.
- 5.Visit https://yourdomain.com/.well-known/security.txt in a browser. It should show your file.
What to put in the file
RFC 9116 makes two fields mandatory. Contact: must always be present. Expires: must also always be present, and must not appear more than once. That second one is missed constantly, because Expires was added in RFC 9116 and older examples do not have it.
Here is a minimal valid file.
Contact: mailto:[email protected]
Expires: 2027-01-01T00:00:00.000ZBoth fields are mandatory. Expires is recommended to be less than a year in the future, which means this file needs recurring maintenance. Put a reminder in your calendar now. An expired security.txt is itself a finding, and a scanner will flag it.
The caveat: check the content type
We will be straight with you about this. RFC 9116 requires the file to be served with Content-Type: text/plain; charset=utf-8. We have not been able to confirm what content type BigCommerce serves for a file uploaded this way, and we are not going to pretend otherwise.
It probably serves it as text/plain, given the extension. But probably is not confirmed, so test it. Open your browser's developer tools, go to the Network tab, load https://yourdomain.com/.well-known/security.txt, and look at the response headers. You want to see text/plain.
If it comes back as something else there is no header control available to fix it on BigCommerce, since the header settings only cover CSP, HSTS and X-Frame-Options. Serving it as text/html would violate the spec. In practice most tools reading your security.txt will still find your contact details, which is the actual point of the file, but a strict validator may object.
The rest of RFC 9116, briefly
A few rules worth knowing so you get it right first time.
- →The location is fixed. It must be at /.well-known/security.txt. Not at the root, not on a page you made in the CMS.
- →It must be served over https. That is not a problem on BigCommerce, where every store gets a certificate automatically.
- →A CMS page will not do. If you publish the content as an ordinary web page, it is served as text/html, which breaks the content-type requirement. It needs to be a real file.
- →Redirects only run one way. The RFC sanctions redirecting from the legacy /security.txt to /.well-known/security.txt, not the reverse. Since BigCommerce lets you serve the real file, this is academic for you.
- →Expires must be under a year out. So this is not a set-and-forget file. Diarise it.
One thing this folder cannot do
Worth knowing so you do not go looking: the .well-known folder you create via WebDAV cannot be used for SSL validation. If you are chasing a certificate problem, that is a different path. Our SSL guide for BigCommerce covers the DCV records you may need instead.
What we would actually do
Upload the two-line file. Set a calendar reminder for eleven months out to bump the Expires date. Check the content type once while you are there. That is the whole job, and it is more than most stores on any platform have done.
Then confirm it is live with a free check, or browse the full fix-it matrix to see what else your store is missing.
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 BigCommerce store?
Yes. Upload it via WebDAV to content/.well-known/security.txt and it is served at /.well-known/security.txt. BigCommerce documents that mapping. This is a real advantage over Shopify, Wix and Squarespace, where merchants cannot publish this file at all.
What must a security.txt file contain?
Two fields are mandatory under RFC 9116. Contact:, giving a way to reach you, and Expires:, a date the file stops being valid. Expires is the one people miss, because it was added by RFC 9116 and older examples predate it. Anything else is optional.
Will BigCommerce serve the file with the right content type?
We cannot confirm this, so test it rather than trust it. RFC 9116 requires text/plain; charset=utf-8. Load the file with your browser's Network tab open and check the response headers. If it is wrong, there is no header control on BigCommerce to fix it, though most tools will still read your contact details regardless.
Can I just make a page called security.txt in BigCommerce instead?
No. A CMS page is served as text/html, which violates the content-type requirement, and it would not sit at /.well-known/ anyway. Use the WebDAV method and upload a real file.
Do I have to update security.txt regularly?
Yes, and this catches people out. The Expires date is recommended to be less than a year in the future, so the file needs renewing roughly annually. An expired security.txt is a finding in its own right, so set a reminder when you upload it.