The short answer
Wix is unusually direct about this. In Wix's own words, "it's not possible to add or customize security response headers, via code or otherwise, unless you have the Wix Studio enterprise solution."
That is the whole picture. There is no plan upgrade, app, or code snippet on a standard Wix site that changes your response headers. The enterprise solution exposes exactly five: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, Referrer-Policy and Permissions-Policy.
Wix's pages on this are feature-request pages that are actively collecting votes, so this is a "currently", not a forever. Worth re-checking in a year.
What Wix already gives you
Some good news before the bad. Wix sets a couple of these for you, and one is guaranteed rather than just observed.
Supported by default on all Wix sites. It stops browsers guessing file types. This one is documented by Wix, not just observed.
At the time of writing, Wix sites respond with HSTS, so browsers stick to HTTPS on return visits. You do not need to add it, and you could not anyway.
Not sent by default at the time of writing. This is a real gap, and on a standard site there is nothing you can do about it.
Not sent by default at the time of writing. Again, no self-serve fix exists. Do not believe any guide that tells you to add it as a meta tag.
The one header you can actually add
Referrer-Policy is the exception, because it is the rare security header that browsers also honour as an HTML meta tag. If you can inject markup into your site's head, this works:
<meta name="referrer" content="strict-origin-when-cross-origin">Note it is name="referrer", not http-equiv. The http-equiv form is not the correct one for this. This only helps if you have a way to add head markup to your Wix site; if you do not, there is no alternative route.
Two things that look like solutions but are not
These come up constantly, and both waste real time.
- →Velo http-functions do not set headers on your site. They set headers only on your own endpoints under the fixed /_functions/ prefix. Your homepage, product pages and everything a visitor actually loads are unaffected.
- →Velo routers do not set HTTP headers at all. A router controls which page renders for a URL. It is not a place to attach response headers, no matter how the code reads.
- →X-Frame-Options as a meta tag does nothing. Browsers ignore it entirely. This is true everywhere, not just on Wix. Plenty of blog posts still recommend it.
- →HSTS cannot be set by meta tag. It is header-only by specification. Wix already sends it, so this is moot, but it is worth knowing before you go hunting.
- →CSP via a meta tag only half works. Some directives apply, but frame-ancestors, report-uri and sandbox are ignored in meta form, which strips out most of the reason you wanted CSP.
Why the Cloudflare workaround does not work on Wix
On some platforms you can put Cloudflare in front of your site and inject headers there. On Wix you cannot, and this is worth saying plainly so you do not spend a weekend on it.
Wix requires DNS-only records. In Wix's words, "Currently, Wix does not support proxied DNS records for domain connections", and it tells you to make sure both A records and CNAME records are set to DNS Only. DNS-only means traffic never passes through Cloudflare's edge. No proxy means no Transform Rules and no Workers, which are the two mechanisms that would have added the headers.
This is the clearest no in this whole area. The workaround is not risky on Wix. It simply does not function.
What we would actually do
Add the Referrer-Policy meta tag if you have a way to inject head markup. Then let this one go. A scanner that counts headers will mark your Wix site down, and there is genuinely nothing you can do about most of it short of the enterprise solution or leaving the platform.
Put the effort where you still have full control. Your SPF record and DMARC record live in DNS, not in Wix, so nobody is blocking you there. Those stop people sending fake email in your name, which hits real customers far more often than clickjacking does.
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 headers on Wix with Velo code?
No. Wix states that it is not possible to add or customize security response headers, via code or otherwise, unless you have the Wix Studio enterprise solution. Velo http-functions only set headers on your own /_functions/ endpoints, and Velo routers do not set HTTP headers at all.
Does upgrading my Wix plan give me security headers?
Not a normal plan upgrade. Only the Wix Studio enterprise solution exposes them, and it exposes exactly five: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, Referrer-Policy and Permissions-Policy.
Can I put Cloudflare in front of Wix to add headers?
No. Wix currently does not support proxied DNS records for domain connections and requires A and CNAME records to be set to DNS Only. Without the proxy there are no Transform Rules and no Workers, so there is no way to inject headers.
Does Wix set any security headers for me?
Yes, some. X-Content-Type-Options is supported by default on all Wix sites. At the time of writing Wix sites also send HSTS. No Content-Security-Policy or X-Frame-Options was observed, and those are the real gaps.
Will a failed security headers check hurt my Wix site?
It will show as a finding, and on Wix you cannot fully clear it. What matters more is whether the things you can control are in order: a valid certificate, HTTPS everywhere, and email authentication. Run your site through our free check to see where you actually stand.