LOW-CODE SECURITY VULNERABILITIES: WHAT AI BUILDERS MISS

Why low-code apps start insecure

Low-code platforms sell a compelling promise: build without understanding the underlying technology. Drag components, connect data sources, deploy. But when a platform hides the backend from you, it does not eliminate security risk — it hides it. You cannot secure what you cannot see, and many low-code builders come from product, design, or founder backgrounds where SQL injection and access control were never part of the job.

The core problem is a mismatch between responsibility and visibility. The platform gives you tools to configure security but does not force you to use them, because defaults that prioritize ease of development make the first hour feel magical. Databases start open, APIs start public, and the security settings live in advanced panels most builders never open. AI builders like Lovable and Bolt add a second layer: they generate real backends (Supabase tables, Edge Functions, API routes) that the builder cannot meaningfully review, so the question shifts from “did I configure this correctly” to “did the generator configure this correctly” — and the honest answer is often no. The abstraction that makes building fast is exactly what makes auditing hard: visual workflow logic has no source file to run a scanner against.

Platform-permission defaults

The single most consequential setting on any low-code platform is what an unauthenticated request can read or write by default — and on most platforms, the default is far too much. Bubble data types have no privacy rules until you add them, meaning every record is findable by anyone until a rule says otherwise. Supabase-backed builders like Lovable expose the anon key in the client by design; any table the generator created without a Row Level Security policy is readable and writable by the whole internet. Auto-generated CRUD APIs (the Base44 pattern) follow predictable REST conventions, so an attacker who finds one endpoint can enumerate the rest.

The subtler version is frontend-only enforcement. The app distinguishes admin, editor, and viewer roles — in the UI. The buttons are hidden, but the underlying API endpoints accept requests from any authenticated user, and sometimes from no user at all. A related shape: fetching a whole table to the browser and filtering client-side, so the “private” records are sitting in the Network tab of every visitor’s DevTools. Multi-tenant apps built this way leak across organizations the moment someone edits an API call.

The fix direction is the same on every platform: treat server-side permission configuration as the application’s actual security model, and treat the UI as decoration. Every data type needs an explicit rule, every table needs RLS with policies you have tested using the public key, every generated endpoint needs an authentication and ownership check. The Supabase RLS checker automates the Supabase case; the pattern write-up naked databases covers what open defaults look like from the attacker’s side.

Integration credential sprawl

Low-code apps are integration-heavy by nature — Stripe, OpenAI, SendGrid, Twilio, Airtable — and every integration is a place for credentials to leak. The dominant failure is API keys in the client: pasted into a frontend component, or placed in an environment variable that the build tool inlines into the public JavaScript bundle (the classic Vite/Next prefix confusion, common in Bolt-generated apps). Anyone who views source gets a Stripe secret key, an OpenAI key with billing attached, or a SendGrid key that sends mail as your domain.

Three adjacent shapes complete the class. Webhook endpoints that skip signature verification let anyone POST a fake “payment succeeded” event and get premium access — see Stripe webhooks and paid trust. Overprivileged keys turn a small leak into a total one: a single full-permission key where a scoped, restricted key would have contained the damage. And when builders do the right thing and proxy API calls through a backend function, the proxy frequently ships without rate limiting or auth, so attackers use it as a free relay — an OpenAI bill can escalate dramatically overnight.

The rules are absolute: secret keys live server-side only (Edge Functions, API routes, platform backend logic); every webhook verifies its signature with the provider’s library; every key is scoped to minimum permissions; every proxy endpoint gets auth and rate limits. Run the token leak checker against your deployed app to find keys already in the bundle.

Admin-URL exposure

Low-code platforms multiply the number of privileged surfaces attached to an app, and most builders only think about the one their users see. There is the app itself, but also the platform’s editor, preview or staging URLs, auto-generated admin panels, and internal tools wired straight into production databases. These surfaces fail in characteristic ways: admin pages that are merely unlinked rather than access-controlled (“hidden” URLs get found — by crawlers, by browser history sync, by guessing /admin), preview links that bypass the production login entirely, and internal tools shared by link where the link is the only credential.

Internal-tool platforms concentrate this risk. A Retool app typically connects with a privileged database user, so the app’s sharing settings — not the database’s — become the real access control; a link shared too broadly, or permission groups left unconfigured, hands broad query access to anyone in (or sometimes outside) the org. Site builders have a lighter version of the same issue: password-protected pages on Webflow or Framer protect page rendering, while CMS content and form endpoints may remain fetchable directly.

Fix direction: inventory every URL attached to the app — editor, preview, staging, admin, API base — and require real authentication on each, not obscurity. Gate internal tools with the platform’s permission groups and audit who holds share links. The pattern write-up hosting panels and internal surface covers the enumeration an attacker performs.

Workflow logic bypass

Visual workflows are the low-code replacement for backend code, and they inherit a specific flaw: the sequence you drew is enforced by the UI, not by the server. A checkout workflow that runs “collect payment, then mark order paid, then grant access” can often be entered at step three, because each step is backed by an API action that does not verify the preceding steps happened. Attackers replay the final API call directly, skip payment, and get the outcome.

The same class covers parameter tampering (the workflow trusts a price or role value that originated in the browser), state skipping in multi-step onboarding or KYC flows, and workflows triggered by events the builder assumed only the platform could fire. Because workflow logic lives in a visual editor, no static analysis tool will flag any of this — it is only visible by testing the app from outside, replaying and reordering the API calls the UI makes. Fix direction: every step that grants value must itself verify server-side that its preconditions are real (payment confirmed with the processor, role read from the database, prior step recorded), never inferred from the client’s claim that the flow was followed. The adjacent money-path failures are covered in race conditions in money paths.

Per-platform starting points

The four classes above show up on every platform, but each platform has its own defaults and its own audit checklist. We keep the detailed, platform-specific analysis on dedicated pages — start with the one you build on:

• Is Bubble safe? — privacy rules, API Connector key handling, search constraints
• Is Retool safe? — permission groups, privileged datasource credentials, link sharing
• Is Webflow safe? — CMS exposure, form endpoints, password-page limits
• Is Framer safe? — published-site surface and integration handling
• Is Lovable safe? — generated Supabase backends and RLS coverage
• Is Bolt safe? — env-var handling and bundle exposure
• Is Base44 safe? — auto-generated API endpoints and auth defaults

How to audit a low-code app

You often cannot read the source, so audit from the outside in:

1. Watch the network. Use the app normally with DevTools open. Flag any response containing data the UI does not show, and any request carrying a key or secret.
2. Replay without auth. Copy API requests and re-send them with the auth token stripped. Data coming back means the endpoint, not the login page, is your real perimeter — and it is open.
3. Check platform permissions directly. RLS on every Supabase table (test with the anon key), privacy rules on every Bubble data type, permission groups on every Retool resource.
4. Grep the bundle for secrets. View source and search the built JavaScript for sk-, key, secret, and provider-specific key formats.
5. Attack the workflow order. Call the last step of paid or gated flows directly. Tamper with prices, roles, and IDs in requests.
6. Fake a webhook. Send an unsigned payload to every webhook endpoint; processing it is a finding.
7. Enumerate privileged URLs. Try /admin, staging and preview URLs, and shared links from outside the org.
8. Re-audit after platform updates. Platforms change defaults; what was secure last month may not be today.

Automated scanning covers the mechanical half of this list on every deploy — the Vibe Code Scanner tests deployed low-code and AI-built apps for open endpoints, leaked keys, missing RLS, and broken access control, and the free security self-audit walks through the manual half.

Related resources

• AI Code Vulnerability Taxonomy — the full class catalog for generated code
• AI-Generated Code Risk Analysis — why builders and generators produce these gaps
• Vibe Coding Vulnerabilities — the prompt-built app view of the same territory
• OWASP Top 10 for AI Code — mapping to OWASP categories
• Supabase RLS checker and Firebase scanner — point tools for backend defaults