Webflow Security: Is Your Site Actually Safe?

Webflow's hosting keeps your server safe — it doesn't check the code, forms, and integrations you added on top of it, and that's where most Webflow sites actually get compromised.

This is for agencies and freelancers running client sites on Webflow, and Webflow site owners who assume "Webflow is secure" means the whole site is covered. You'll get a plain-English breakdown of what Webflow's hosting actually protects, the four risk areas it doesn't touch, and a 10-minute checklist you can run on any Webflow site today — plus how to think about it if you resell security audits as part of your client work.

What Webflow's hosting actually protects

Webflow is a managed platform, and that buys you real security out of the box. Its hosting runs behind a CDN with automatic SSL/TLS, infrastructure-level DDoS mitigation, and automated backups — you don't manage a server, so there's no unpatched Linux box or outdated PHP version for an attacker to exploit the way there often is on a self-hosted WordPress install.

But "managed hosting" only covers the parts Webflow itself controls. Everything you build on top of that — custom code, forms, integrations, content — is your responsibility, same as on any platform.

This is the gap that shows up in almost every Webflow audit we run: the platform itself is solid, but the things a builder added — a Zapier webhook, a tracking script, a "quick fix" embed — are where the actual exposure lives.

The four risks Webflow hosting doesn't cover

1. Leaked API keys in custom code embeds

Webflow's Custom Code panel (Site Settings → Custom Code, or an Embed element on a page) is one of its most useful features — and one of the easiest ways to leak a secret. Anything typed into an embed is delivered as plain client-side HTML/JavaScript, meaning anyone can see it by right-clicking → View Page Source.

We regularly find live API keys for tools like Airtable, Google Maps, Mailchimp, Zapier, and CRMs sitting in plain view inside embeds — usually copy-pasted straight from a tutorial. A key with write access in the wrong hands can mean spam data injected into a CRM, a maxed-out API bill, or a foothold into a connected tool.

Hard-coding secrets into client-facing code is a well-documented anti-pattern: OWASP's Secrets Management Cheat Sheet and the CWE-798: Use of Hard-Coded Credentials weakness class both cover it directly. The fix: any key that needs to stay secret belongs in a server-side function or a proxy — never in an embed the browser can read.

2. Unprotected form submissions

Webflow Forms come with basic honeypot-style spam filtering, but that's not the same as rate limiting or bot protection. Left on defaults, a public form is an open door for:

• Automated spam floods that fill your (or your client's) inbox and CMS
• Bots probing form fields for weak input validation
• Fake leads polluting sales data

OWASP catalogs this class of abuse under Automated Threats to Web Applications. To close the gap: turn on reCAPTCHA in the form element's settings, restrict what fields accept (no open file uploads unless genuinely required), and don't route submissions anywhere that could be used to spoof internal emails or phish your team.

3. CMS data exposed through the API

Webflow's CMS is genuinely well-built, but "CMS item" and "private data" aren't automatically the same thing. Two patterns show up repeatedly:

• A collection meant for internal use (draft content, pricing tiers, internal notes) gets published because "unpublished" only hides it from the live site, not from anyone with the direct API access an integration might have.
• A Webflow API token — used to power custom filtering, search, or a headless front end — gets embedded in client-side JavaScript instead of a backend, exposing read/write access to every collection it can reach.

Treat any Webflow API token the same as a database password: server-side only, scoped to the minimum access it needs, and rotated if you're ever unsure where it's been pasted.

4. Security headers you have to set yourself

Response headers like Content-Security-Policy, X-Content-Type-Options: nosniff, and Strict-Transport-Security tell the browser how to defend the page against things like clickjacking and script injection — but most Webflow plans don't give you a direct panel to set them. If your plan doesn't support custom headers, the practical fix is fronting the site with a service like Cloudflare, which can inject these headers at the edge without touching Webflow itself.

OWASP's Secure Headers Project is the reference for what each header does and recommended values. Run your live site through our security headers checker to see exactly which ones are missing — it takes about ten seconds and needs nothing installed.

A 10-minute self-check for any Webflow site

Run through this on your own site, or a client's, before assuming it's fine:

1. View source on every page with an embed. Search for key=, token=, apikey, or secret — anything that looks like a credential shouldn't be there.
2. Check every form's settings for reCAPTCHA or spam protection and confirm exactly where submissions get sent.
3. List every third-party integration (Zapier, Make, Airtable, Google Sheets, a CRM) connected to the site and confirm none of their keys live inside Webflow's custom code.
4. Scan for security headers using a header-check tool and note what's missing.
5. Review CMS collections for anything published that shouldn't be public — draft content, internal pricing, staff data.
6. Check for an orphaned staging subdomain (.webflow.io) still live and indexable after launch.

If more than one or two of these turn up something, it's worth getting a second pair of eyes on it rather than guessing at severity yourself.

Why "it's on Webflow, so it's secure" is a trap for agencies

If you build or manage sites for clients, "Webflow is secure" is a sentence clients repeat back to you — and it's true just enough to be dangerous. Webflow's hosting is genuinely solid infrastructure, but a client breached through a leaked Zapier key sitting in their homepage's embed code won't care that the servers were fine. The exposure was in what your team built, and that's exactly the layer an automated scanner tends to skim past, because scanners test infrastructure patterns, not the specific embed a designer pasted in eight months ago. Our guide comparing manual vs. automated penetration testing covers why a human reading the actual page source catches this class of issue that tooling alone tends to miss — it's why agencies increasingly bundle a manual pass into every Webflow handoff instead of a one-line "we use Webflow, so you're covered."

Key takeaways

• Webflow's hosting secures the servers, SSL, and uptime — it does not check your custom code, forms, integrations, or CMS data for you.
• Anything typed into a Custom Code embed is publicly visible via View Source, including any API key pasted there by mistake.
• Turn on reCAPTCHA on public forms and never route form data anywhere an attacker could use it for phishing.
• Treat Webflow API tokens like passwords: server-side only, minimum scope, never in client-facing JavaScript.
• Missing security headers (CSP, HSTS, X-Content-Type-Options) are on you to add — usually via a proxy like Cloudflare if your plan doesn't support them directly.

If your self-check turned up a stray API key, a wide-open form, or you're just not sure what's actually exposed on a Webflow build you inherited, that's exactly what a manual audit is for. Circuit is a $49 one-time check where a real person reads the actual page source, tests the forms, and hands you a written report of what's exposed and how to fix it — not another automated scan re-flagging the same generic warnings. Or start with our free passive security check if you just want a quick read on where things stand.