Webflow security guide: scripts, forms and API tokens

By Thunkle · Platform references checked 19 September 2026

A Webflow security review should match the site you have built. A public marketing site is not the same as a customer portal with a member provider, custom API and private documents. Review the added code and integrations without inventing a database risk for a static page.

Our Webflow security audit examines the published site and agreed integrations. The practical starting point is an inventory of what runs in the browser and where submitted data goes.

Use developer review where the site connects to services

For Webflow, developer review is most valuable where custom scripts, forms, member systems and APIs connect. An experienced reviewer can follow a submission to its destination, identify privileged operations and check which system enforces access. A public brochure site needs a proportionate scope; adding private documents, paid membership or operational integrations changes what should be verified.

Our paid Webflow security audit offers a developer-led audit scoped to the site's actual scripts and connected systems. We document evidence and remediation priorities, with a free re-review of agreed fixes. Implementation can be scoped separately when you need help changing the integrations.

Map custom scripts and their access

List site-wide scripts, page-specific embeds, tag-manager entries, consent tools and third-party widgets. Note who maintains each script and why it is needed. A remote script running in the page may have access to information available in that page, so its presence deserves an explicit decision.

Inspect the published output as well as the designer configuration. A script may be injected by another service, and a removed component may leave an unrelated site-wide integration in place. Avoid treating an editor-only view as a complete inventory of production.

For scripts you control, review DOM insertion, input handling and external requests. Do not paste untrusted content into executable HTML or send private form fields to analytics merely because an integration makes it easy.

Keep privileged API tokens off the client

Webflow documents API token scopes that govern permitted actions. Choose credentials appropriate to the integration rather than granting broad access by default. Webflow API overview.

A browser-delivered script is not a safe place for a privileged management token. If a feature needs a trusted server component, that component must also authenticate or constrain the caller. Moving the token behind an unrestricted proxy can leave its powers available to everyone indirectly.

Distinguish public configuration from real credentials. Report a value according to its capabilities and intended use, not just a string pattern. If a privileged token was exposed, revoke or rotate it and investigate its use; deleting the visible string is not enough.

Trace a synthetic enquiry from form to destination

Consider a quotation form collecting a name, email and project brief. Identify every destination: form storage, notification inbox, CRM, webhook and any analytics event. Confirm that each destination receives only the data intended for it.

In an authorized test setup, use synthetic details and a controlled inbox. Check input validation at the receiving service, abuse controls and what happens on repeated submissions. A success message is not evidence that data reached the correct account or that downstream access is restricted.

Do not use real client enquiries to test integrations. If a test would send an external email or create a production record, agree that action first or use a safe test destination.

Review external membership and private content separately

If a member system or custom backend sits behind Webflow, identify where access is enforced. A hidden section is not proof that its content was withheld from the browser. Check the actual response and direct asset URLs for each relevant account.

For a synthetic member library, verify an entitled member can download a document and an unentitled account cannot. Then test the intended result after membership is revoked. Preserve the successful case so a missing file is not mistaken for a correct denial.

Account for preview and published origins

Webflow documents that custom-code previews use a separate preview origin. A component that works there may behave differently after publishing. Configure external services for the specific intended origins rather than broadly weakening restrictions to make a preview work. Webflow custom-code preview guidance.

Review access to the Webflow workspace, integration accounts and domain administration as part of operational ownership. Remove unneeded collaborator access through the normal approved process; do not assume offboarding from one service removes access from all of them.

Does HTTPS make the whole site secure?

HTTPS protects transport. It does not establish that a script, token, form destination or connected membership rule is appropriate.

What should a site audit cover?

The published pages, scripts, forms and integrations agreed in scope, with evidence and limitations. No audit can guarantee that every vulnerability is absent.

Request a security audit quote with the site URL and connected services. We agree authorized tests and deliver prioritized findings with practical fixes. Implementation can be scoped separately; agreed fixes receive a free re-review. Do not include tokens or customer submissions.