WEBFLOW SECURITY CHECKLIST

Webflow is mostly a static site builder, which makes its security posture straightforward — except where teams add custom code embeds, hook up the CMS API, or accept user input via forms. Each of those touchpoints is where Webflow security typically fails: API tokens pasted into custom code embeds, form webhooks pointed at unauthenticated URLs, and third-party scripts that haven’t been re-audited since they were added two years ago. The checklist below is what we look for first when we audit a Webflow site.

Treat Critical as launch-blocking. High is week-one. Medium is the cleanup once the site is live.

How to use this checklist

Walk it once in the Webflow Designer for your published site, ticking items as you go. After each fix, re-publish and re-test against the live URL. After the whole list passes, run a black-box scan against the production domain.

Critical (fix before launch)

1. Strip CMS API tokens from custom code embeds

Why it matters. Webflow’s CMS API is meant to be called server-side. Custom code embeds that paste an API token into client-side JavaScript expose the token to anyone viewing the source — and the token has read/write access to your entire CMS, depending on scope.

How to check. Read every custom code embed in Project Settings → Custom Code and per-page custom code. Search for Bearer followed by tokens, webflow.com/api, and any string that looks like a credential.

How to fix. Move CMS API calls to a server-side proxy (Cloudflare Worker, Vercel function, Netlify function). Rotate any token that ever appeared in client code.

2. Lock CMS collection visibility before launch

Why it matters. CMS collections can have unpublished items, draft items, and items with private fields. Webflow exposes published items via the CMS API and via dynamic templates — but draft items can leak via “preview” URLs that haven’t been password-protected.

How to check. Audit each CMS collection. Confirm draft and unpublished items are intentional; confirm preview URLs (if any) require auth.

How to fix. Publish or delete drafts as appropriate. Disable preview URLs for collections containing pre-launch content.

3. Audit form submission destinations

Why it matters. Webflow forms can submit to Webflow’s collector, to email, or to webhooks. Webhook endpoints sometimes accept POSTed form data without verification — meaning a leaked webhook URL becomes an open data ingest point. Worse, the webhook URL is visible in the page source.

How to check. Read every form’s Action and webhook configuration. For webhook destinations, confirm the receiving endpoint validates the request (signature, allowed origin, secret token).

How to fix. Use Webflow’s collector or a signed-webhook destination (Zapier, n8n, your own backend with HMAC verification). Never use unauthenticated open webhooks.

4. Verify password protection on staging URLs

Why it matters. Webflow’s *.webflow.io staging URLs are publicly reachable. Pre-launch content, unpublished pages, and CMS drafts ship to a URL search engines can crawl.

How to check. Project Settings → General → Password Protection. For unlaunched sites, password protection should be on for the staging URL.

How to fix. Enable password protection. For sites that have launched but use a separate staging environment, password-protect the staging.

5. Remove debug code and console.log from custom embeds

Why it matters. Custom code embeds added during development sometimes contain console.log statements that dump session data, user IDs, or API responses. This is information leakage to anyone with DevTools open.

How to check. Read every custom code embed. Search for console.log, console.debug, alert(, and debugger;.

How to fix. Remove or comment out before publish. Add a custom-code review step to your launch checklist.

6. Audit user accounts on the site

Why it matters. If you use Webflow’s Memberships or User Accounts feature, the account list is part of your attack surface. Test accounts created during development sometimes ship with weak passwords or with admin-equivalent permissions.

How to check. User Accounts. Audit for test accounts, weak passwords, and unused admin accounts.

How to fix. Delete test accounts. Enforce password policy on user-created accounts. Require email verification.

High (fix in the first week)

7. Configure SSL and HSTS on the custom domain

Webflow provides automatic SSL on custom domains. Enable HSTS in Project Settings → SEO → Custom Code via a meta tag, or via your CDN if you front Webflow with one.

8. Restrict Designer access by role

Audit Project Settings → Members. Designers can change every part of the site (and add custom code). Downgrade where you can.

9. Add CAPTCHA on forms

Webflow integrates with reCAPTCHA. Enable on signup, contact, and any form that creates downstream actions (sending email, creating CMS items).

10. Pin third-party script versions

Custom code embeds for analytics, A/B testing, chat widgets often load latest. Pin to specific versions; audit changelogs before bumping.

11. Verify CMS API tokens have minimum scope

Webflow tokens can be read-only or read-write, scoped per project. Use the narrowest scope each integration needs.

12. Set up monitoring on form submissions

Webflow Forms collects submissions in the dashboard. Monitor for spam patterns; alert on submission spikes.

Medium (fix when you can)

13. Audit third-party scripts in the custom code section

Each script is attack surface. Scripts that load JS from third-party CDNs run in your origin and can read your cookies. Audit; remove unused.

14. Configure CSP via project settings

Webflow lets you add custom HTML in the head. Use a CSP <meta> tag (with caveats — header-based CSP is stronger; use it via your CDN if available).

15. Document collection schema changes

When CMS collections evolve, custom code that depends on field names breaks. Document changes; communicate to integrations.

16. Restrict who can publish to the live domain

Webflow’s “Publish” is the deploy. Restrict to a small group; require change documentation.

17. Audit Webflow apps and integrations

Each installed app has scopes. Audit; remove unused.

18. Verify domain DNS is locked

Custom domains use DNS records you manage. Audit registrar access.

After every site change

• Re-test custom code embeds — confirm no new credentials slipped in.
• Re-test forms — confirm CAPTCHA still fires, webhook destinations still verify.
• Re-publish staging password protection if relevant.

Common attack patterns we see in Webflow sites

The pasted CMS token. Developer added a custom code block that calls the CMS API “to fetch latest items dynamically.” Token is in the embed; readable in source.

The open form webhook. Form posts to a Zapier webhook. Webhook URL is in the page source; attacker scripts a million submissions; Zapier quota burns through.

The leaked staging. New marketing site staged at <project>.webflow.io; no password protection. Search engine indexes pre-launch pricing; competitors find it.

The stale tracking script. Added a chat widget two years ago; never updated. Widget vendor was acquired and the new owner’s CDN now serves a different script — including auth-cookie-stealing JS.

Related Resources

How to Secure Webflow

Step-by-step guide for hardening a Webflow site — custom code hygiene, form configuration, third-party script policy, and the password-protection patterns above in long form.

Is Webflow Safe?

In-depth analysis of Webflow’s defaults — what’s locked down, what depends on your custom code choices, and what we find when we audit a typical Webflow site.

Automate Your Checklist

A checklist tells you what to look for. A scanner tells you what’s actually broken in the live site right now. VibeEval drives a real browser through your Webflow site, attempts the credential-leak and form-abuse attacks above, and reports what got through.