FRAMER SECURITY CHECKLIST

Framer is a design-first site builder with React code components — which is the source of both its expressiveness and its most common security failure. Code components run in the user’s browser; whatever credentials they reference get bundled to the client. Combined with public preview links that index pre-launch content and forms that submit to whatever endpoint a designer pointed them at, most Framer security issues live at the boundary between the design tool and your real backend. The checklist below is what we look for first when we audit a Framer 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 Framer editor 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 API keys from code components

Why it matters. Framer code components are bundled into the published site. Any credential referenced in a code component — even via process.env-style patterns Framer might support — ends up in the client bundle, readable to anyone with DevTools.

How to check. Read every code component in Components → Code. Search for Bearer patterns, recognizable key prefixes (sk_, re_, sk-proj-), and any string that looks like a credential. Open the published site’s bundle and grep for the same.

How to fix. Move auth-bearing API calls to a server-side proxy. Use the proxy URL in the code component instead of the third-party endpoint. Rotate any token that ever appeared in a component.

2. Lock CMS collection visibility before launch

Why it matters. Framer’s CMS supports unpublished items, scheduled items, and collections that aren’t yet linked from any page. Publishing the site makes them all reachable as routes — /blog/draft-q3-launch works even if no menu links to it.

How to check. Audit each CMS collection. Confirm draft items are intentional. Audit the published site’s sitemap; look for routes you didn’t expect.

How to fix. Unpublish or delete drafts. Configure CMS to exclude unpublished items from sitemaps and from the build.

3. Audit form submission destinations

Why it matters. Framer forms can submit to email, to Framer’s collector, or to webhooks. Webhook destinations sometimes accept POSTed data without verification — and the URL is in the page source.

How to check. Read every form’s submission destination. For webhook destinations, confirm the receiving endpoint validates the request (HMAC, allowed origin, secret token).

How to fix. Use Framer’s built-in collector or a verified-webhook destination. Reject unauthenticated webhooks for production data.

4. Disable preview links that contain unpublished content

Why it matters. Framer preview links bypass page password protection and can include CMS drafts. Designers share these links freely; they get indexed if shared publicly.

How to check. Project Settings → Sharing. Audit which preview links are active and what they expose.

How to fix. Disable preview links you no longer need. For active previews, restrict access where Framer allows.

5. Remove debug overlays from production publish

Why it matters. Framer code components sometimes include debug overlays — visible variant indicators, “design mode” toggles, hidden admin links. These ship to production unless removed.

How to check. Walk the published site in DevTools. Look for hidden elements (display: none toggleable via console), debug data attributes, and console output from custom components.

How to fix. Strip debug code from components before publish. Add a pre-publish review step.

6. Verify forms validate on the server

Why it matters. Framer forms validate on the client by default. If the form posts to your backend, the backend must re-validate — or attackers POST garbage that you accept.

How to check. For each form, confirm the receiving endpoint applies the same validation as the client.

How to fix. Validate server-side. Whitelist field names; reject extras.

High (fix in the first week)

7. Configure custom domain SSL and HSTS

Framer provides automatic SSL on custom domains. Enable HSTS via your CDN or via a meta tag in the site head.

8. Restrict team access by role

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

9. Add CAPTCHA on forms

Framer integrates with reCAPTCHA. Enable on contact, signup, and any form that creates downstream actions.

10. Pin third-party script versions

Custom code in components for analytics, A/B testing, chat widgets often loads latest. Pin specific versions; audit changelogs before bumping.

11. Verify no secrets are exposed via Framer’s environment

If your team uses Framer’s variables / environment for configuration, confirm secrets aren’t in there (or that they’re only referenced server-side, if Framer adds that).

12. Set up monitoring on form submissions

Monitor form submission patterns. Alert on spikes that suggest spam or scraping.

Medium (fix when you can)

13. Audit third-party embeds and scripts

Each embed (calendars, payment widgets, video players) runs in your origin and can read your cookies. Audit; remove unused; pin sources.

14. Document component prop boundaries

For each code component, document which props are safe to expose in the editor and which would be dangerous (URLs that get used as endpoints, etc.).

15. Remove unused code components

Old components accumulate. Delete what’s not used; smaller surface area.

16. Restrict who can publish to live

Framer’s publish is the deploy. Restrict to a small group; require change documentation.

17. Audit Framer plugins / integrations

Each integration 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 code components — confirm no new credentials slipped in.
• Re-test forms — confirm CAPTCHA still fires.
• Re-publish; re-confirm preview link policy.

Common attack patterns we see in Framer sites

The pasted API key. Code component for a “live status” widget paste the third-party API key inline. Bundle ships; key visible to anyone in DevTools.

The leaked draft. CMS draft items reachable as routes; competitors find pre-launch announcements in robots.txt.

The unauthenticated webhook. Form posts to a Make.com webhook URL pasted into the form’s Action. Anyone can spam the webhook; Make quota burns through.

The stale chat widget. Embedded chat widget loads JS from a vendor’s CDN. Vendor was acquired; new owner serves auth-stealing JS in the same script tag.

Related Resources

How to Secure Framer

Step-by-step guide for hardening a Framer site — code component hygiene, form destinations, third-party script policy, and the preview-link patterns above in long form.

Is Framer Safe?

In-depth analysis of Framer’s defaults — what’s locked down, what depends on your component choices, and what we find when we audit a typical Framer 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 Framer site, attempts the credential-leak and form-abuse attacks above, and reports what got through.