Framer security guide: components, forms and webhooks

By Thunkle · Platform references checked 19 September 2026

Framer site security is often about the code and services attached to the design. Components, scripts and form destinations can process private information or invoke privileged services even when the site itself is a public marketing page.

A useful review follows those connections. It does not assume every Framer site has authentication or private database tables. Our Framer site security audit defines the relevant scope before testing.

Have a developer follow forms beyond the page

A Framer form may start a workflow that continues through a webhook, automation and external service. A developer should review that full path, including validation, credentials and repeated delivery, alongside the code shipped to visitors. This is especially useful when the design looks finished but the services behind it now handle leads, sensitive submissions or business-critical actions.

Thunkle's paid Framer site security audit follows the agreed components and connected services in a developer-led audit. Findings include evidence and actionable remediation guidance. We re-review agreed fixes free; implementing component or backend changes is a separate scope.

Inventory code components and published-page scripts

List the code components, embeds, site settings scripts, analytics and third-party widgets that run on the published pages. Record which ones receive form values, contact external APIs or fetch content.

Inspect the published output rather than relying only on the editor or a plugin result. Different tools can see different parts of a project. Our Framer plugin visibility article explains why scan coverage needs to be stated explicitly.

For each external script, know its purpose, provider and maintenance owner. Review whether it needs access on every page, especially pages containing forms or user-specific information. A small tracking snippet is still executable code with an effect on visitors.

Move privileged operations behind a controlled backend

A component calling a paid API should not embed a privileged provider credential in browser-delivered code. Use a suitable trusted backend where needed, then review that backend's own caller checks, accepted inputs and usage limits.

An unrestricted proxy can hide the credential while exposing the same paid operation to arbitrary callers. Define whether the feature is public, account-bound or restricted to staff, and enforce that policy where the action executes.

Not every public configuration value is a secret. Classify the actual capability before reporting a leak. If a real privileged credential has reached a browser, follow the provider's revocation or rotation process and investigate use rather than only removing the component.

Verify form webhooks at the receiver

Framer documents optional signature verification for form webhooks, including a submission identifier and a signature derived from the payload. It also documents delivery retries. Use its current verification guidance at your receiving service. Framer form webhook documentation.

The signature addresses the source and integrity of the delivery. It does not make visitor-provided field values trustworthy or mean that a submission should trigger any requested action. Validate fields and apply the business rule before creating records or invoking providers.

Our recommendation is also to handle repeated delivery intentionally. A repeated accepted submission should not unintentionally create duplicate jobs, invitations or charges. Use the integration's documented identifiers and a design appropriate to the receiver rather than assuming delivery occurs exactly once.

A synthetic consultation form test

In an authorized test environment, configure a controlled destination and submit synthetic contact details. Verify that the receiver accepts a legitimate submission, rejects a request that fails the configured verification, and handles repeated delivery without duplicating an action that should occur once.

Check stored data and the test inbox, not only the browser's success message. Confirm that internal errors do not disclose provider credentials or unnecessary personal information. Avoid live customer emails, CRM records or payment actions during routine testing.

If the form includes a field such as “plan” or “price,” treat it as a visitor request. The receiving service must decide the authoritative price or entitlement where relevant; the visitor's field value is not an authorization decision.

Review private content only if it exists

For a site connected to a membership or document service, test the actual backend and download path. Hiding a link does not establish that the resource is inaccessible. Use separate entitled and unentitled accounts, synthetic documents and an existing successful download as a control.

If all content is intentionally public, focus the audit on scripts, forms, integrations, credentials and operational access. A smaller honest scope is more useful than a long checklist for systems the site does not have.

Is a clean plugin scan enough?

It is useful evidence within the plugin's stated coverage. Compare that coverage with the scripts, published pages and external services in your inventory.

When should I get a site security audit?

Before collecting sensitive submissions or adding custom components and integrations you cannot confidently review. No audit can guarantee the absence of all vulnerabilities.

Get a security audit quote. Share the published URL and integration list, not credentials or real submissions. We agree scope and permitted actions first, then provide evidence-backed findings and fixes. Implementation can be scoped separately; agreed fixes receive a free re-review.