The short answer
In Webflow's own words: "Custom security headers are only available to Webflow Enterprise customers." That covers Content-Security-Policy, X-Frame-Options, X-Content-Type-Options and Referrer-Policy, plus HSTS through Advanced publishing options.
If you are not on Enterprise, you have three real options. You can add a Referrer-Policy meta tag in your head code. You can put Cloudflare in front of your site, which Webflow officially supports. Or you can accept the defaults, which already include HSTS.
We will cover all three, and be honest about the sharp edges in each.
What you already get without Enterprise
Two things are worth knowing before you go shopping for a fix.
HSTS is enabled automatically for every non-Enterprise Webflow site, and it cannot be disabled. This is the header most small sites are missing elsewhere. You have it by default.
Non-Enterprise sites have this option in publishing settings. Webflow does not name the exact headers it sets, so we will not guess. Turn it on, then test your live site to see what actually lands.
The inverse HSTS logic, explained
This trips people up, so it is worth stating plainly. Webflow does the opposite of what you would expect.
Non-Enterprise sites: HSTS is on automatically and you cannot turn it off. Good for security, no action needed.
Enterprise sites: you get a toggle in Advanced publishing options, which means HSTS is something you control and can therefore forget to enable.
So paying more can actually leave you with weaker defaults if nobody flips the switch. If you are on Enterprise, check that toggle. Read more on what HSTS actually does before you enable it, and never enable preload before HTTPS works across every subdomain.
The one header you can add yourself, on any plan
Referrer-Policy is the rare security header that also works as an HTML meta tag. If you can inject head code, you can set it, no Enterprise required.
Add this to your site or page head code in Webflow:
<meta name="referrer" content="strict-origin-when-cross-origin">Note it is name="referrer", not http-equiv. That is the correct form and browsers honour it.
What does not work as a meta tag
Before you copy anything else from a blog post, know the limits. Meta tags are not a general substitute for HTTP headers.
- →X-Frame-Options as a meta tag does nothing at all. Browsers ignore it completely. Plenty of guides still recommend it.
- →HSTS is header-only by specification. There is no meta tag version. Webflow already sends it on non-Enterprise sites anyway.
- →CSP works partly as a meta tag, but frame-ancestors, report-uri and sandbox are ignored in meta form. Those are the directives you most want.
- →Referrer-Policy is the exception, which is why the snippet above is worth adding.
What Enterprise actually gives you, and its catches
Enterprise unlocks real custom headers: CSP, X-Frame-Options, X-Content-Type-Options and Referrer-Policy, plus the HSTS toggle. There are three catches worth knowing before you start a sales conversation.
- →It is not self-serve. Webflow Sales unlocks the feature per site. You cannot turn it on yourself, even on Enterprise, until that happens.
- →Webflow disclaims support for it. Their words: "our support and success teams are unable to provide direct help with setup or troubleshooting." You are on your own with your CSP.
- →Headers are not editable. To change a value you delete the header and add it again. Fiddly when you are iterating on a CSP.
Permissions-Policy is not supported
Worth stating so you do not go looking. Permissions-Policy is not supported on Webflow, on any plan. If a scanner flags it, that gap is not closable inside Webflow itself.
The Cloudflare route, which Webflow officially supports
This is the good news, and it is genuinely better than what most hosted platforms offer. Webflow officially supports putting Cloudflare in front of your site, using what Cloudflare calls Orange-to-Orange, or O2O. Once traffic runs through your own Cloudflare zone, you set whatever headers you want with Transform Rules or Workers.
A free Cloudflare zone plan works. You do not need Webflow Enterprise. You do not need a Cloudflare paid plan.
The conditions and traps:
- →Your site must be migrated to Cloudflare first. Webflow's words: "You can only use O2O if your site's been migrated to Cloudflare. Sites created after April 21, 2025 are already on Cloudflare." Older sites may not be. Check before you plan the work.
- →SSL mode must be Full (Strict) in your Cloudflare zone. Get this wrong and things break in confusing ways.
- →Do not just orange-cloud your existing records. Naively proxying legacy DNS records throws a 525 Handshake Error and your site goes down. Follow the migration path properly.
- →A Cloudflare Zone Hold blocks Webflow SSL issuance. If your certificate will not provision, check for a zone hold first. It is a quiet failure mode.
The self-managed reverse proxy path
Webflow also documents running your own reverse proxy in front of your site. That gives you complete header control, and complete responsibility for uptime, caching and certificates. It is a real option if you already run infrastructure.
One hard rule: never proxy *.webflow.io. Proxying your staging subdomain violates Webflow's terms of service. Proxy your live custom domain only.
What we would actually do
If you are on a normal Webflow plan and not in a hurry: add the Referrer-Policy meta tag, turn on "Use secure frame headers", and test what your live site sends. HSTS is already handled. That covers most of what a scanner will ask about.
If you need a real CSP, go the Cloudflare route. It is officially supported, free, and does not require a sales call. Just do the migration properly rather than flipping the orange cloud and hoping.
While you are at it, your SPF record and DMARC record live at your registrar, so nothing is gating those. They protect your customers from fake emails sent in your name, which is a far more common attack than clickjacking.
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 Webflow without Enterprise?
Not natively. Webflow says custom security headers are only available to Enterprise customers. You can still set Referrer-Policy with a meta tag in your head code, and you can put Cloudflare in front of your site to set any header you want. Cloudflare in front is officially supported by Webflow and a free Cloudflare zone plan works.
Do I need to enable HSTS on my Webflow site?
On a non-Enterprise site, no. HSTS is enabled automatically and cannot be disabled. On Enterprise it becomes a toggle in Advanced publishing options, so check that it is actually on. The logic is inverted from what most people expect.
Will Webflow help me set up my CSP on Enterprise?
No, and they say so upfront. Webflow states that "our support and success teams are unable to provide direct help with setup or troubleshooting" for custom security headers. The feature also is not self-serve, so Sales has to unlock it per site. Headers cannot be edited either, you delete and re-add them.
Can I use Cloudflare in front of Webflow?
Yes, and unlike some platforms Webflow officially supports it. A free Cloudflare zone plan is enough and no Webflow Enterprise is needed. Your SSL mode must be Full (Strict), and your site must already be migrated to Cloudflare. Sites created after 21 April 2025 already are. Do not simply orange-cloud legacy records, that causes a 525 Handshake Error.
Can I set Permissions-Policy on Webflow?
Not through Webflow, on any plan. It is not supported. If you need it, the Cloudflare route is your option.
Does adding an X-Frame-Options meta tag work?
No. X-Frame-Options as a meta tag has no effect at all, on Webflow or anywhere else. Browsers ignore it. Webflow does offer a "Use secure frame headers" option on non-Enterprise sites, though it does not name the exact headers it sets, so test your live site to confirm.