The short answer
security.txt has to live at a specific path: /.well-known/security.txt. On Wix you cannot put a file there. Wix confirms it on its own feature-request page for root files.
There is no plan, no app and no code workaround. This one is a straight no, and we would rather tell you that in one paragraph than sell you an afternoon of trying.
Because it is a feature-request page still collecting votes, this is a "currently". It may change. Today it has not.
What security.txt is meant to do
It is a small text file that tells a security researcher who to contact when they find a problem with your site. It is defined by RFC 9116.
The value is real if slightly narrow. Someone finds a genuine flaw, they look for security.txt, and it tells them how to reach you privately instead of tweeting about it or giving up. Without one, well-meaning people often cannot find a way in and the problem stays unreported.
More detail on our security.txt glossary entry.
What the spec actually requires
Worth knowing, because it explains why the workarounds do not count. RFC 9116 says the file:
- →MUST be at /.well-known/security.txt. Not at /security.txt, not on a page. That exact path.
- →MUST be served over https.
- →MUST be served as Content-Type: text/plain; charset=utf-8. Publishing the text as an ordinary CMS page serves it as text/html, which breaks this outright.
- →MUST have a Contact field. The RFC's words: "This field MUST always be present."
- →MUST have an Expires field. Also mandatory, must not appear more than once, and should be less than a year in the future. This is the field most existing files are missing, because it only arrived with RFC 9116.
What a valid file looks like
For reference, this is a complete and valid security.txt. It really is this small.
Contact: mailto:[email protected]
Expires: 2027-01-01T00:00:00.000ZBoth fields are mandatory. Because Expires must be less than a year out, this file needs recurring maintenance. An expired security.txt is itself a finding, so an abandoned one is worse than none.
Why a redirect does not save you
The obvious idea is to put the text somewhere Wix allows and redirect /.well-known/security.txt to it. Two problems.
First, whether Wix even accepts a redirect from that path is unconfirmed, so we are not going to promise you it works.
Second, and this is the part that settles it: the RFC sanctions redirects from the legacy top-level /security.txt to /.well-known/security.txt. Not the reverse. A redirect pointing away from /.well-known/ is not what the spec describes, so even a working one would not fully satisfy it. You would also still have the content-type problem, since a Wix page is served as HTML.
What to do instead
Skip the file and solve the actual problem, which is that a researcher needs a way to reach you.
- 1.Create a security contact page on your Wix site. A short page is fine. Say who to contact and how, and give a real monitored address.
- 2.Link to it from your footer, so it is reachable from every page. This is the bit that matters. A page nobody can find helps nobody.
- 3.Use an address you actually read. security@ is conventional and easy to guess, which is the point. An unmonitored inbox is the same as no inbox.
- 4.Say what you want reported and how you will respond. Even one honest sentence makes people more likely to bother.
Keep it in proportion
Being honest about scale: a missing security.txt is a low-severity finding. It is not an open door. It is a missing signpost. On Wix you cannot fix it, and no amount of effort will change that today.
The checks that carry real weight are the ones you can still act on. Your SPF and DMARC records live in DNS, entirely outside Wix's control, and they stop people sending phishing email in your name. That protects real customers. Do those first.
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 Wix site?
No. Wix does not let you host an arbitrary file at /.well-known/, which is confirmed by Wix's own feature-request page for root files. Since RFC 9116 requires the file to be at exactly /.well-known/security.txt, there is no way to do this properly on Wix today.
Can I use a redirect to fake it?
We would not rely on it. Whether Wix accepts a redirect from that path is unconfirmed, and more importantly the RFC only sanctions redirects from the legacy /security.txt to /.well-known/security.txt, not the reverse. A Wix page would also be served as text/html, which breaks the required text/plain content type.
Can I just make a page called security.txt on Wix?
It will not satisfy the spec. RFC 9116 requires Content-Type: text/plain; charset=utf-8, and a CMS page is served as HTML. It also has to be at /.well-known/security.txt, which Wix does not allow. As a human-readable security contact page it is still worth having, just do not expect it to pass the check.
How bad is a missing security.txt?
Low severity. It is a missing signpost, not an open door. It means a researcher who finds a problem may not be able to tell you about it. Worth solving with a clearly linked security contact page, not worth losing sleep over.
What must a security.txt file contain?
Two mandatory fields: Contact and Expires. Expires was added in RFC 9116 and is the one most existing files are missing. It should be less than a year in the future, which means the file needs recurring maintenance. An expired security.txt is itself a finding.