FIGMA MAKE SECURITY CHECKLIST

Figma Make turns design frames into working web apps in minutes. The security risk is exactly that speed: the apps it generates are designed to demo, not to ship — they use placeholder backends, store auth state in design tokens, and frequently expose Figma comments and unpublished frames at the URLs they generate. The checklist below is what we look for first when we audit a Figma Make app that’s about to go live.

Treat Critical as launch-blocking. High is week-one. Medium is the cleanup once you have users.

How to use this checklist

Walk it once on the published Make app, ticking items as you go. After each fix, re-publish — Figma Make rewrites code on every regeneration and a passing item can fail next time. After the whole list passes, run a black-box scan against the published URL.

Critical (fix before launch)

1. Replace the placeholder backend with an auth-enforced API

Why it matters. Figma Make ships with a built-in mock backend so the app “just works” without any setup. The mock backend has no auth, no per-user scoping, and no rate limits. Connect it to a real frontend without replacing the backend and every user shares a single state.

How to check. In the Make app, identify whether useFigmaMakeBackend(), figma.make.db, or similar mock APIs are still in use. Any reference to the platform-provided in-memory store is a placeholder.

How to fix. Replace with calls to a real backend (your API, Supabase, Firebase) before launch. The real backend must enforce auth and per-user scoping.

2. Strip Figma API tokens from generated code

Why it matters. Make generates code that occasionally embeds Figma personal access tokens “to fetch the latest design”. Tokens with files:read scope let an attacker read every file you have access to in Figma — including unreleased product designs.

How to check. Search the generated code for figd_, figma_pat_, Bearer fig. Search the deployed bundle for the same patterns.

How to fix. Move any Figma API calls to a server-side proxy. Rotate any token that ever appeared in client code. Use minimum-scope tokens.

3. Add server-side validation to every form

Why it matters. Make exports React forms that call the placeholder backend (which trusts everything) or your real backend with no schema validation. Drop client validation in DevTools, submit garbage, and the request often succeeds.

How to check. For every form in the Make export, identify the backend it posts to. Confirm the backend validates the body against an explicit schema before any database write.

How to fix. Validate in the server handler with Zod, Valibot, or a manual schema. Whitelist fields explicitly; reject extras.

4. Verify generated routes don’t expose unpublished frames

Why it matters. Make sometimes generates routes for every frame in the source Figma file, including drafts, comments, and unreleased pages. Publish, and /draft-pricing-page-q3 is reachable to anyone who guesses the URL — or to anyone who reads the JS bundle’s route table.

How to check. Open the deployed app’s bundle and extract the route table (grep -E 'path:' bundle.js). Confirm every route is intentional. Search for routes containing “draft”, “wip”, “v2”, “internal”, “admin”, “test”.

How to fix. Delete unintended routes from the Make config before publish. Double-check after every regeneration.

5. Move secrets out of frontend env

Why it matters. Make’s “connect a service” UX often produces code that references API keys via import.meta.env.VITE_* or process.env.NEXT_PUBLIC_* — both of which inline values into the client bundle.

How to check. Search the generated code for VITE_ and NEXT_PUBLIC_. For each match, confirm the value is intentionally public (publishable key, public URL, anon key). Any secret-shaped value is a leak.

How to fix. Move secret-bearing API calls to a backend route or serverless function. Rotate anything that lived in a public env var.

6. Confirm auth-required routes actually require auth

Why it matters. Generated route guards live in the React component, not in the backend. Drop the auth check in DevTools and the page renders; whether the API also enforces auth determines whether you have a real bug or a cosmetic one.

How to check. For every protected route, hit its backend endpoint with no auth header (curl https://your-api/profile). It should return 401, not 200.

How to fix. Move authorization to the API. Frontend guards exist only to redirect to login.

High (fix in the first week)

7. Configure CSP and CORS for the host

Whatever you publish to (Vercel, Netlify, custom), add CSP that restricts script-src and a CORS allowlist on the backend. Make’s exports don’t configure either.

8. Audit generated state management for secret leakage

Make often persists Zustand/Redux state to localStorage, including auth tokens or backend responses. Move tokens to httpOnly cookies; persist only non-sensitive UI state.

9. Pin generated dependency versions

Make resolves “latest” at generation time. Pin every dependency in package.json and commit the lockfile so production builds match what you tested.

10. Verify the published app respects design-time access controls

If frames in the source Figma file are restricted to certain teammates, confirm the generated app doesn’t inadvertently make those frames public. Publishing the app effectively makes every included frame world-readable as a route.

11. Audit any third-party integrations Make wired up

Stripe, Resend, OpenAI, etc. Confirm credentials are server-only, scopes are minimum, and webhook handlers (if any) verify signatures.

12. Disable email enumeration if Make wired up auth

If Make wired up Clerk, Auth0, or Supabase Auth, set the auth provider to return identical responses for “user exists” and “user does not exist” on signup, password reset, and magic link.

Medium (fix when you can)

13. Document which Figma frames map to which routes

When the source design changes, you want a list of routes that may have changed too. Maintain a frame → route mapping in your repo.

14. Re-test security after every Make regeneration

Regenerations rewrite security-critical code. Re-run smoke security tests after every regeneration that touches a backend call.

15. Remove design-tool-specific debug helpers

Make sometimes leaves “Open in Figma” buttons or design-time helpers in the production export. Delete them.

16. Restrict who can publish the Make app

Audit publishing permissions in Figma. Anyone with publish rights can ship code to your domain.

17. Set up monitoring on the published URL

Standard web monitoring (uptime, error rate) plus security monitoring (unusual traffic patterns) on the Make-published domain.

18. Audit any installed Figma plugins that touch Make

Plugins can read your Make app’s state and the Figma file behind it. Audit installed plugins; remove anything not strictly needed.

After every Make regeneration

• Diff the route table — confirm no unintended routes appeared.
• Re-check the generated bundle for figd_, VITE_*, NEXT_PUBLIC_*.
• Re-test auth-required routes with no auth header.
• Confirm the placeholder backend hasn’t been re-introduced.
• Verify integrations still use the secure proxy you set up.

Common attack patterns we see in Figma Make apps

The placeholder backend in production. Make app shipped with the in-memory mock backend still wired up. Every user’s “private notes” are visible to every other user.

The leaked Figma token. Personal access token embedded in generated code so the app could “show the latest version of the design”. Token works for every Figma file the developer can read; competitor scrapes the unreleased product designs.

The draft-route URL. Make included /pricing-v2-draft because it was a frame in the file. Customer found it via robots.txt; pricing leaked early.

The mass-assigned form. Generated form posts the entire form state to /api/profile. Backend spreads it into a database update. Attacker submits isAdmin=true.

Related Resources

How to Secure Figma Make

Step-by-step guide for taking a Make app from prototype to production-safe — backend migration, auth wiring, CSP setup, and the regeneration workflow.

Is Figma Make Safe?

In-depth analysis of Make’s defaults — what the placeholder backend does, what design metadata leaks into the published app, and what we find when we scan a typical Make app.

Automate Your Checklist

A checklist tells you what to look for. A scanner tells you what’s actually broken in the deployed app right now. VibeEval drives a real browser through your Make publish, attempts the unintended-route discovery and placeholder-backend exploitation above, and reports what got through.