From design to code: what changes when generated frontend meets real data

Tools like Figma Make, Builder.io Visual Copilot, Anima, Tempo, Uizard, and Galileo AI transform mockups, prompts, and visual components into functional interfaces in very little time. The risk does not lie in the tool itself, but in the moment a frontend prototype is connected to APIs, authentication, payments, or real data while maintaining the assumptions typical of a mockup: client-side-only validation, exposed endpoints, tokens in the browser, and role controls entrusted to the interface rather than the backend.

This article is aimed at founders, CTOs, developers, and design engineering teams. The focus is on generated frontend code: forms, validation, API calls from the browser, and mockups that become production code.

Why an app that works is not necessarily secure

AI tools reduce the time needed to create code, interfaces, and workflows, but this speed can compress steps that normally make software reliable: threat modeling, review, secret management, role controls, input validation, dependency verification, and manual testing of critical paths.

A demo works with a single user, dummy data, and implicit permissions. The same logic can fail when real customers, multiple tenants, different roles, public APIs, integrations, personal data, payments, or automations with external effects arrive. Security must be evaluated based on the actual behavior of the app, not the promise of the tool that generated it.

The frontend is not the security perimeter

A generated component can hide buttons, block fields, or filter views in the interface, but this does not replace server-side checks. Everything that runs in the browser is inspectable and modifiable, so authorizations and validation must be enforced by the backend, regardless of what the frontend displays.

Forms, APIs, and tokens: points of attention in the transition from design to code

The transition from design to code introduces forms, fetch calls, SDKs, endpoints, and environment variables. It is essential to verify that no secret tokens end up in the client bundle and that every input is validated server-side, because browser-side validation can be bypassed with elementary tools.

From prototype to production: what to verify before go-live

Before taking an AI-generated interface to production, it is necessary to perform a frontend code review and test the most common vectors: XSS, CSRF where relevant, CORS configuration, unvalidated redirects, file upload handling, error handling, and behavior with users who have different roles.

Main risks to check

The risks that emerge most frequently in generated frontend code concern validation, secret management, and API configuration. For each, it is useful to verify the evidence in the code, the actual configuration, the runtime behavior, and the impact on real data.

• Client-side-only validation: any check performed only in the browser can be bypassed directly on HTTP requests.
• Tokens or keys in browser code: secrets included in the JavaScript bundle are accessible to anyone who inspects the source.
• API calls without robust authentication: endpoints reachable without a valid token or with a token not verified server-side.
• Permissive CORS introduced to make the demo work: open configurations that remain in production due to inertia.
• XSS from dynamic content or LLM output: unsanitized output that is rendered in the DOM without escaping.
• Non-allowlisted redirects and callbacks: OAuth or post-login flows that accept arbitrary URLs.
• Admin components visible or abusable: administrative features hidden in the interface but accessible via API without server-side control.

These risks must always be linked to the concrete perimeter of the application. An app exposed to external users requires manual application testing; a critical code change requires review; an internal workflow requires permission and credential control; an agentic app requires testing on prompts, tool calls, and outputs. The correct combination depends on the impact, not the name of the tool used to generate the code.

Operational checklist before go-live

• Map users, roles, real data, integrations, environments, and service owners.
• Identify which parts were generated or modified with AI and who reviewed them.
• Verify server-side authorizations, tenant isolation, and administrative functions.
• Search for secrets in code, prompts, logs, environment variables, builds, and repository history.
• Check dependencies, licenses, packages, templates, plugins, and generated components.
• Test hostile inputs, error handling, logging, rate limits, and unforeseen paths.
• Separate blocking fixes, planned remediation, and accepted residual risk.
• Repeat the test or retest after corrections that affect critical flows.

When an independent verification is needed

An independent verification is necessary when the app or workflow handles real data, external users, roles, APIs, corporate integrations, payments, storage, automatic workflows, or critical code generated with AI. It is also necessary when the team cannot demonstrate which parts have been reviewed and which controls block regressions or abuse.

In these cases, the perimeter recommended by ISGroup includes Web Application Penetration Testing to verify the behavior of the exposed app, and Code Review to analyze the generated source code. An effective review is not generic: it must produce reproducible findings, remediation priorities, an indication of residual risk, and, when necessary, retesting after corrections.

Operational questions for founders, CTOs, and security teams

• What real data enters the system and where is it saved, logged, or sent?
• What roles exist and which actions are blocked server-side, not just in the interface?
• What secrets, tokens, webhooks, or credentials would allow access to critical systems?
• Which parts were generated or modified by AI and which were reviewed by a competent person?
• Which tests cover abuse, errors, different roles, and different tenants, not just the happy path?
• What evidence can be shown to clients, audits, procurement, or management?

Useful insights

• Security of web apps generated with Vercel’s v0: explores the specific risks of the Vercel platform without overlapping with the focus of this article.
• Code review for AI-generated code: a guide to reviewing code produced by AI tools, with criteria and methodology.
• Authentication and authorization in AI apps: analysis of common auth patterns and risks when logic is automatically generated.

FAQ

• Can generated frontend code be vulnerable?
• Yes. XSS, tokens in the client, misconfigured CORS, browser-only validation, unvalidated redirects, and API abuse are concrete and documented risks.
• What should never be in the browser?
• Secrets, private keys, service tokens, decisive authorization logic, and data not necessary for the current user’s role.
• Is a Code Review needed even for a frontend-only project?
• Yes, if the frontend handles authentication flows, API calls, personal data, dynamic output, payments, or integrations with external systems.
• When is a WAPT necessary?
• When the interface is connected to real backends or APIs and is reachable by external users, even during a beta or soft launch.
• How to prevent the mockup from becoming a risk in production?
• By clearly separating prototype and production, enforcing server-side controls on every sensitive operation, and reviewing the code before connecting real data.

Sources and references

• OWASP Top 10 2021
• OWASP ASVS
• OWASP Code Review Guide
• NIST SP 800-218 SSDF
• Figma
• Builder.io