Is Vibe Coding Safe? Security Risks of AI-Generated Code

Quick answer: Assess the tool’s permissions and data handling separately from the security of the application you build. Review code, deployed configuration, and test coverage before release. Keep secret credentials server-side and inspect client bundles and repositories for exposure. Test server-side authentication and authorization for each protected operation. Prompt for security explicitly and scan every app before launch.

By Paula C · Kraftwire Software

Review generated code and deployment configuration independently of whether visible features work. Specify access requirements, inspect the implementation, and test protected operations. Automated scans add bounded checks; they do not establish that an application is safe to ship.

These live figures describe all scanned sites. They do not establish prevalence for an AI-built subgroup, compare development methods, or attribute findings to AI generation.

30% of the 119 live sites SimplyScan has scanned (36 sites) have at least one high or critical security issue.

The "vibe" alone is not a security strategy.

What Is Vibe Coding and Why Does It Matter for Security?

Vibe coding is a development paradigm where natural language prompts replace manual syntax. Instead of writing useEffect hooks or SQL queries, you "vibe" with an AI agent · using tools like Lovable, Bolt.new, Cursor, or Windsurf · to iterate on a vision until the app works.

Vibe coding still requires review of the generated application. Test its data access, input handling, and deployed configuration instead of inferring security from a working feature.

Combine code review, application-specific tests, and supported automated checks. Each examines a different part of the application.

The average security score across the 119 live sites SimplyScan has scanned is 86 out of 100.

The average summarizes the scanned population. Inspect individual findings and coverage for the application you intend to release.

Where Should You Look For Security Gaps?

1. Test Rejected Requests

Test missing sessions, unauthorized resource IDs, and untrusted input. A successful login or form submission does not show that invalid requests are rejected. Review code injection risks where input reaches an interpreter.

2. Inspect Secrets

Check generated source, repository history, and built assets for credentials. Investigate exposed secrets without inferring how a model learned the pattern.

3. Define Access Requirements

Specify who may read and change each resource, then inspect and test the implementation. A prompt alone does not establish Row Level Security (RLS) or server-side authorization.

11% of the 119 live sites SimplyScan has scanned (13 sites) have at least one medium-severity architecture issue, such as a library with a known vulnerability or no rate limiting.

4. Review Deployment Boundaries

For code built with Windsurf, Cursor, or other tools, review the deployed components together. Test CORS, redirects, and authorization against the intended origins and users.

Six Vibe Coding Vulnerabilities to Check

1. Exposed API Keys and Secrets

SimplyScan checks accessible client bundles for recognizable secret patterns, including OpenAI, Stripe, and Supabase service-role credentials.

• The Risk: A leaked credential grants its holder the permissions associated with that key.
• The Check: Keep secrets in server-side environment variables, check which .env values enter the build, and inspect bundles and repositories with a secret scanner. A clear scan does not prove that no secrets remain.

2. Broken Access Control

A frontend restriction does not enforce access on the backend. Test whether each operation checks the caller’s identity and permissions.

• The Risk: Unauthorized reading or modification of data.
• The Check: Review server authorization and, where applicable, Supabase RLS. Use the broken access control checklist to plan allowed and denied cases.

3. Code Injection and XSS

Inspect uses of dangerouslySetInnerHTML and SQL construction wherever untrusted input can reach them.

• The Risk: Unsafe output handling can execute scripts; unsafe SQL construction can change a query’s meaning.
• The Check: Use context-appropriate encoding or sanitization and parameterized SQL values. Dynamic identifiers need separate validation. See the XSS prevention guide.

4. Insecure Session Management

Test expiration, logout, and server-side session validation.

• The Risk: Stolen or invalidated tokens may remain usable if checks are incomplete.
• The Check: For cookie sessions, review httpOnly, Secure, SameSite, and CSRF protections. The JWT debugger can decode tokens and perform supported signature checks; it does not validate the application’s authorization or revocation behavior. See the JWT security guide.

5. Missing Security Headers

Inspect deployed security headers and test the relevant browser protections.

• The Risk: Increased vulnerability to clickjacking and protocol downgrades.
• The Fix: Use our security headers tool to check your site and apply a CSP guide. Depending on deployment, configure headers through next.config.js, vercel.json, or the applicable server settings. Browser scripts can read localStorage; headers do not make stored tokens inaccessible to all scripts.

6. Vulnerable Dependencies

Check dependency versions against known vulnerabilities.

• The Risk: A vulnerable component may expose the application to attacks, depending on how it is used.
• The Check: Run npm audit for supported dependency advisories and review its coverage. SimplyScan can identify recognizable vulnerable frontend library versions in accessible assets; it does not inventory every server dependency.

Vibe Coding Security Review Checklist

Use a repeatable review process before deployment. This checklist organizes checks without proving readiness:

Secret Audit

Search your codebase for strings like sk-, key=, or password. Scan the deployed bundle and repository for detectable secret patterns. Investigate findings and revoke exposed credentials; a clean result does not prove that no secrets remain. See secret scanner.

Auth Verification

Using test accounts and records you control, log in as User A and attempt to access User B’s private data. Compare the response with the intended policy; unexpected access indicates an authorization problem.

Database Hardening

For Supabase tables exposed to client roles, review privileges and RLS. Disabled RLS leaves access to privileges; enabled RLS with no applicable policy denies access to roles subject to RLS. Permissive policies can expose rows, and bypass roles ignore RLS. See the Supabase checklist.

Input Handling

In an isolated test environment, check how input such as <script> or ' OR 1=1 is handled in the relevant output or query context. These strings are starting points, not exhaustive injection tests.

Security Headers

Ensure Content-Security-Policy is active to mitigate the impact of any accidental XSS.

Automated Scan

Run a SimplyScan report for supported public-response checks. It takes about 30 seconds and grades 8 dimensions, including security, speed, and privacy/compliance signals. It does not certify security or legal compliance.

How to Prompt for More Secure Code

You can improve the "vibe" by changing how you talk to the AI. Instead of asking for a feature, ask for a secure feature.

• Incomplete Prompt: "Create a contact form that saves to my database."
• More Specific Prompt: "Define who may submit the form. Validate inputs on the server, limit submissions, and use the least database privileges needed. Keep secret credentials off the client and add tests for rejected requests."

Specific requirements make the result easier to review, but do not force correct implementation. Test what was generated. See prompt engineering for secure web apps and prompt-injection risks.

Beyond Security: Speed, SEO, and AI Visibility (AEO)

Review performance and discoverability separately from access controls. Measure the deployed application and investigate the affected requests and resources. See Speed and Performance.

79% of the 119 live sites SimplyScan has scanned (94 sites) have at least one medium-severity speed issue, such as render-blocking scripts or no route-based code splitting.

11% of the 119 live sites SimplyScan has scanned (13 sites) have at least one high-severity speed issue, such as render-blocking scripts or no route-based code splitting.

Check bundle size and loading behavior for the affected pages; the aggregate rate does not establish the cause.

For AEO, inspect crawler access, structured data, and text available without client-side execution. The AI visibility tool reports supported signals; it does not prove indexing, ranking, or citation.

The Bottom Line: Trust but Verify

Treat generated code as work that needs review. Neither the development method nor a prompt establishes the resulting application’s security.

29% of the 119 live sites SimplyScan has scanned (35 sites) have at least one medium-severity web-security issue, such as a missing Content-Security-Policy or HSTS header.

13% of the 119 live sites SimplyScan has scanned (15 sites) have at least one high-severity web-security issue, such as a missing Content-Security-Policy or HSTS header.

Investigate the findings on the affected applications.

For apps built with Bolt, Lovable, or other tools, use SimplyScan findings alongside code review and authenticated testing. Investigate what the scan did not cover.

Scan your vibe-coded app for free →

FAQ

Is vibe coding safe for founders with no technical background?

Assess the tool’s permissions and data handling separately from the application’s security. Arrange code review and authenticated testing before release. A security audit checklist and automated scans can help organize checks, but do not substitute for expertise in areas they cannot verify.

How do I know if my AI-generated app is leaking data?

Test intended private operations with no session and with separate test users. Inspect returned fields and compare them with the access policy. SimplyScan checks publicly observable headers and recognizable exposed secret patterns; it does not establish authenticated cross-user isolation.

Can I rely on Cursor or Windsurf to write secure code?

Review the output, especially authentication logic, database queries, and deployment settings. The editor’s name and a working feature do not prove security. Combine code review, authenticated tests, and automated checks with known coverage.

Which security risks in bolt.new and lovable apps should I check?

Review Supabase roles and table privileges, inspect for exposed service-role secrets, and test CSRF protection and input handling. Review the platform configuration and generated code before deployment. Issues like these can lead to data exposure.

How does SimplyScan help with vibe coding security?

SimplyScan grades 8 dimensions, including security, speed, and AI visibility, using supported public-response checks. Its badge links to a dated scan’s score and eligibility state. Follow the verification link and review the badge criteria; it does not prove the absence of vulnerabilities.

Is it possible to optimize vibe-coded apps for AI search engines?

Review crawler access, metadata, structured data, and content available without client-side execution. SimplyScan’s AI visibility check reports supported signals. These checks do not guarantee indexing, ranking, or citation by an answer engine.