Vibe Coding Security: How to Ship AI-Built Apps Without Getting Hacked

1. Broken Access Control

This is the single most common vulnerability in vibe-coded apps, and the one AI tools are structurally worst at. The pattern is consistent: the AI checks whether a request comes from a logged-in user, and then trusts whatever ID that user supplies. Change the number at the end of /api/invoices/1042to 1043 and you are reading someone else's invoice. Security researchers call this an insecure direct object reference, or IDOR. The 2026 audit of 200 deployed AI-built apps found broken access control was the leading vulnerability class, and Tenzai found every agent it tested skipped ownership checks somewhere.

The fix is a discipline, not a library: every query that returns or mutates a resource must be scoped to the current user or their organisation, and every admin-only route must verify the admin role on the server, not just hide the button in the UI. Tell your AI tool explicitly, in a rules file, that authentication and authorization are separate checks and both are required.

2. Authentication Vulnerabilities

Authentication is the front door to your application, and AI-generated auth code consistently leaves it unlocked. The most common issue is missing rate limiting: without it, an attacker can attempt thousands of password combinations per second with no friction. AI tools also generate sessions that never expire, meaning a stolen token grants permanent access.

Other frequent gaps include predictable password reset tokens (sequential IDs or short numeric codes that can be brute-forced), missing multi-factor authentication, and session tokens that are not invalidated on password change. If you built auth with an AI tool, these are the first things to check. See the full authentication checklist for a complete audit guide.

3. Exposed API Keys and Secrets

AI coding assistants frequently place API keys directly in source code. When you ask an AI to integrate with Stripe, Resend, or any third-party service, it often hardcodes the key in the file where it is used rather than referencing an environment variable. If that file is client-side JavaScript, the key is visible to anyone who opens browser dev tools. The August 2026 scan of nearly 31,000 live AI-built apps found one in 23 shipping secrets in public bundles or config files. Escape's scan of 5,600 apps found more than 400.

Even when keys land in server-side code, they end up committed to git history where they persist after deletion. Without secret rotation and proper environment variable management, a single exposed key can grant attackers access to your payment processor, email service, or database. Put a secret scanner in CI so this class of mistake cannot reach main. The monitoring checklist covers how to detect and prevent secret exposure.

4. Misconfigured Databases and Missing Row-Level Security

Most vibe-coded apps use a hosted backend such as Supabase or Firebase, where the browser talks to the database directly using a public key and the database itself enforces who can read what. That model is secure only if row-level security policies are enabled and written correctly. AI tools routinely create tables without enabling RLS, or generate a policy of USING (true) to make the feature work, which grants every visitor access to every row.

This was the mechanism behind CVE-2025-48757, where 303 endpoints across 170 Lovable-built projects were readable or writable without logging in. Over a year later the problem has grown, not shrunk: the August 2026 scan found 57% of reachable Supabase-backed apps still permitted unauthenticated table reads, and 16% of all apps scanned allowed anonymous users to modify or delete data. If your app uses a hosted backend, verifying every table's policies is the highest-value hour you can spend.

5. Missing Input Validation: Injection and XSS

When AI generates forms, API endpoints, or database queries, it typically trusts user input implicitly. Form fields accept any value without length limits or format validation. API endpoints pass request bodies directly to database queries. User-submitted content renders in the browser without sanitization.

These patterns enable the most common web vulnerabilities: SQL injection (manipulating database queries through form fields), cross-site scripting or XSS (injecting JavaScript that runs in other users' browsers), and command injection (executing system commands through unsanitized input). Models have largely learned to avoid SQL injection, which Veracode now measures at an 82% to 86% pass rate. XSS is a different story: only 15% of generated code defended against it in the Spring 2026 tests, because doing so requires tracking data across the request handler, the template, and the client. A single unsanitized field can compromise every user who visits your site.

6. Insecure File Uploads

File upload is one of the most exploited attack vectors on the web, and AI-generated upload handlers are almost always missing critical safeguards. A typical implementation accepts any file, stores it in a publicly accessible directory, and uses the original filename, which opens the door to path traversal, executable uploads, and storage abuse.

Secure file upload requires validating both the MIME type and file extension, enforcing size limits, generating random filenames, storing files outside the web root, and scanning for malware. Most AI tools implement none of these by default. Review the file uploads checklist to see what your implementation may be missing.

7. Missing Security Headers and CSRF Protection

Security headers are the cheapest defence on the web. A content security policy blunts XSS. X-Frame-Options stops clickjacking. HSTS prevents protocol downgrade attacks. Every one of them is a few lines in your framework's config, and AI tools almost never add them because no tutorial does. In Tenzai's study, none of the 15 apps built by five different agents set a single security header, and none had CSRF protection.

Cross-site request forgery matters whenever your app uses cookie-based sessions: without a SameSite attribute or an anti-CSRF token, a malicious page can make your logged-in user's browser submit requests they never intended. If your app uses bearer tokens in an Authorization header you are largely covered. If it uses cookies, check.

8. Server-Side Request Forgery

Any feature that fetches a URL the user supplies is an SSRF risk: link previews, webhook registrations, “import from URL”, image proxies, PDF generators. AI tools implement these by passing the URL straight to a fetch call. An attacker supplies an internal address, such as a cloud metadata endpoint or an admin service on localhost, and your server dutifully retrieves it for them.

Tenzai found that every one of the five agents it tested introduced SSRF. It is one of the clearest examples of a context-dependent vulnerability: fetching a URL is fine, fetching an arbitrary user-controlled URL from a privileged server is not, and the model cannot tell the difference without being told. Resolve and validate the destination, block private and link-local ranges, and allowlist where you can.

9. Insecure Payment Handling

Payment integration is where security gaps become directly expensive. AI-generated payment code often processes sensitive operations client-side, where they can be manipulated. Price calculations happen in the browser. Subscription status is checked by reading local state rather than verifying with the payment provider. Webhook endpoints accept payloads without verifying signatures. Tenzai's e-commerce test apps accepted negative quantities and prices.

Without idempotency keys, network retries can charge customers multiple times. Without webhook verification, attackers can forge payment confirmations and access paid features for free. The payments checklist walks through every critical check for AI-generated payment code.

10. Hallucinated and Vulnerable Dependencies

AI tools add packages freely, and not all of them are real. The Cloud Security Alliance analysed 2.23 million AI-generated code samples from 16 models and found 19.7% referenced at least one package that does not exist. Attackers register those names on npm and PyPI and wait, a technique now called slopsquatting. When the next developer's AI suggests the same phantom package, it installs the attacker's code.

Even real packages carry risk. AI tools have no sense of whether a library is maintained, how many downloads it has, or whether it has open CVEs; they reach for whatever appeared most often in training data, which skews old. Audit every dependency the AI added: confirm it exists, check its maintenance status, and run a vulnerability scanner in CI.

Tell the AI what secure looks like, once

Every major coding tool reads a rules file from your repository: CLAUDE.md for Claude Code, .cursor/rules for Cursor, AGENTS.md for Codex and others. Put your security requirements there so they apply to every session instead of every prompt. The requirements that pay off most: every data access must be scoped to the current user; secrets come from environment variables only; every API route validates its input with a schema; new tables get row-level security enabled before any code uses them; never disable a security feature to make a test pass. This directly addresses the memory and objective defects the research identifies, because the constraint is re-read on every turn.

Validate at the boundary

Define a schema for every request body, query string, and form submission using Zod or an equivalent, and reject anything that does not match before it reaches business logic. This one habit eliminates most injection, type-confusion, and mass-assignment bugs, and it gives the AI a concrete pattern to copy. Pair it with parameterized queries or an ORM for database access and an auto-escaping template layer for output.

Authorize every resource, not just every request

Middleware that confirms a user is logged in is necessary and not sufficient. Each handler must also confirm the user is allowed to touch the specific record they asked for. The cleanest implementation is a data-access layer where every query takes the current user and filters by ownership, so it is impossible to forget. If you use Supabase or Firebase, that layer is your row-level security or security rules, and every table needs a real policy.

Make the secure default the only default

Some protections should not depend on the AI remembering them. Set security headers in your framework config or hosting platform once. Turn on rate limiting at the edge or in middleware for auth routes. Add a secret scanner such as gitleaks to CI so a hardcoded key fails the build. Enable dependency auditing in CI. These guardrails are invisible during day-to-day vibe coding and catch the mistakes that matter most.

Verify before you ship, and again after every big change

Instructions and guardrails reduce the error rate. They do not take it to zero, and AI tools make different decisions in every session. A systematic scan of the whole codebase before launch, and after any feature that touches auth, payments, uploads, or user data, is the step that separates the teams that ship safely from the ones in the statistics. The next section shows how to do it in a few minutes.

Step 1: Install

From the root of your project, run one command. It detects which coding tool you use and installs the right skill files.

npx skills add Hypership-Software/vibe-check

Step 2: Run the check

In Claude Code, run the check skill. In Cursor the same skill is invoked as @vibe-check check, and in VS Code Copilot as #vibe-check check. To scan only the security domain, pass it as the focus.

/check
/check security

The check asks four short context questions (what you are building, who it is for, what data it handles, what is at stake), maps your codebase, then runs a specialised assessor for each production domain in parallel. Domains that do not apply to your project are skipped. The security assessor checks nine items against your real code:

• Secrets management — no hardcoded keys, tokens, or connection strings in code or git history
• Authentication — hashed passwords, expiring sessions, protected routes
• Input validation — schema validation at every API boundary, parameterized queries
• Dependency security — no known CVEs, no unmaintained or hallucinated packages
• HTTPS — enforced on every route with HSTS
• Security headers — CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy
• CORS configuration — explicit origin allowlist, never wildcard with credentials
• CSRF protection — SameSite cookies or anti-CSRF tokens on state-changing routes
• Rate limiting — on login, signup, password reset, and public API endpoints

Step 3: Read the score

You get a score out of 100 and a band: Production Ready (90+), Launch Ready (75 to 89), Needs Work (60 to 74), or Early Stage (below 60). Critical security failures gate the band: an app that scores 92 but has a hardcoded API key is capped at Needs Work until the key is removed, so a good overall score can never hide a dangerous finding. Every finding comes with a priority, an explanation calibrated to your context, and a fix instruction written for your AI tool.

Step 4: Fix and re-check

Run the fix skill to walk through findings one at a time. It proposes the change and applies it only after you approve. When you are done, or a week later after more vibe coding, re-run to see what improved and whether anything regressed.

/fix
/refresh