When no-code becomes an application risk

Bubble AI, Glide AI, Softr AI, Webflow AI, Wix AI, and Framer AI reduce the distance between an idea and publication, but they do not eliminate application risks. In fact, they often shift them into configurations, permissions, visibility rules, public forms, workflows, and integrations that are not treated as code, despite having the same impact as a vulnerability.

The point is not to determine whether AI is useful or dangerous for development. It is much more practical: understanding what controls are needed when a result generated or accelerated by AI enters a product, a business workflow, or an environment with real data. This article is aimed at founders, CTOs, developers, and IT/security teams, and focuses on poorly managed authentication, record-level permissions, public forms, file uploads, API integrations, automations involving personal data, and shadow IT.

Why an app that works is not necessarily secure

AI tools compress the time required to create code, interfaces, workflows, and configurations. This speed, however, can skip the steps that make software reliable: threat modeling, review, secret management, role control, 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. This is why security must be evaluated based on the actual behavior of the app, not on the promise of the tool that generated it.

The risk is in the configuration, not just the code

In Bubble, Glide, Softr, Webflow, Wix, or Framer, the problem is rarely a line of vulnerable code. More often, it is a missing access rule, an exposed form, a database readable without authentication, a public file, or an automation that sends data to the wrong service. These elements do not appear in a traditional source code review, but they produce the same effects as a critical vulnerability.

Shadow IT and personal data

No-code apps are often born in marketing, operations, or business units, outside the IT perimeter. If they collect personal data, attachments, contracts, leads, or customer information, they must be brought under IT/security governance, even if they do not pass through a repository. The absence of custom code does not equate to the absence of risk: it equates to the absence of visibility.

How to test a no-code app

Verification must use users with different roles, records belonging to different customers, public links, uploads, exports, endpoints, automations, integrations, and admin panels. Looking only at the interface is not enough: many vulnerabilities emerge only by simulating real behaviors with different credentials or by accessing the underlying endpoints directly.

Main risks to check

• Missing record-level permissions: verify configuration, runtime behavior, and impact on the real data of different customers.
• Public forms that are exploitable or subject to spam: verify exposure, absence of rate limiting, and the possibility of unauthorized data insertion.
• File uploads without controls: verify type, size, destination, and public accessibility of uploaded files.
• Shared links that expose data: verify if generated links are guessable, lack authentication, or have no expiration.
• Workflows that send data to third parties: verify recipients, activation conditions, and data transmitted in every automation.
• API keys inserted into ungoverned integrations: verify where they are stored, who can read them, and if they are rotated periodically.
• Admin roles granted to business users: verify which actions are blocked server-side and not just in the interface.

These risks must be linked to the concrete perimeter. An exposed app requires manual application testing; a critical code change requires review; an internal workflow requires control of permissions and credentials. The correct combination depends on the impact, not the name of the tool.

Minimum controls 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 input, error handling, logging, rate limiting, and unexpected 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

Independent verification is needed 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 needed when the team cannot demonstrate which parts have been reviewed and which controls block regressions or abuse.

For these types of contexts, the perimeter recommended by ISGroup includes Vulnerability Assessment, Web Application Penetration Testing, and, when the development cycle requires it, Code Review. The best 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?
• What tests cover abuse, errors, different roles, and different tenants, not just the happy path?
• What evidence can be shown to customers, audits, procurement, or management?

FAQ

• Can no-code have application vulnerabilities?
• Yes. Permissions, forms, uploads, integrations, data, and automations can expose information or allow unauthorized actions, regardless of the absence of custom code.
• Is WAPT needed if there is no custom code?
• Yes, when the app is exposed and handles real data. The test verifies behavior, permissions, and attack surfaces, not just the source code.
• What is the most important control?
• Verifying record-level permissions and roles with different users, especially regarding customer data and administrative functions.
• How to manage apps created by business units?
• With an inventory, data classification, IT/security approval, rules on integrations, and an assessment proportional to the actual risk.
• When is VA enough and when is WAPT needed?
• VA helps with exposure and configurations; WAPT is necessary to analyze application flows, roles, data, and function abuse.

Useful insights

• AI-generated Shadow IT: how to recognize and govern AI tools adopted outside the corporate IT perimeter.
• Security controls before go-live: operational checklist to verify an AI app or workflow before production deployment.
• Exposed database in vibe coding: analysis of the specific risk of data exposure in apps generated with vibe coding approaches.

Sources and references

• OWASP Top 10 2021
• OWASP ASVS
• OWASP Code Review Guide
• NIST SP 800-218 SSDF
• Bubble security
• Glide security