SaaS Security Checklist for AI-Assisted Development

Speed is the whole point of AI-assisted development. You describe what you want, the code appears, you ship. The problem is that the security gaps get shipped right along with the features.

Veracode's 2025 GenAI Code Security Report tested over 100 large language models across four languages and found that 45% of AI-generated code samples contained vulnerabilities from the OWASP Top 10. That figure hasn't improved over time. Bigger models don't do better either. The researchers concluded this is a systemic issue, not a scaling problem. Meanwhile, Aikido Security's 2026 data puts AI-generated code as the source of one in five breaches.

The developers getting burned aren't careless amateurs. One developer went viral building his entire SaaS with Cursor and zero hand-written code. Two days after launch, his API keys were being maxed out by strangers, users were bypassing subscriptions, and random records were appearing in his database. No authentication, no rate limiting, no input validation. He shut it down. This story is not unique.

If you're building with AI coding tools like Cursor, Copilot, or Claude, this checklist covers what the AI consistently gets wrong and what you need to verify yourself before anything touches production.

The AI Doesn't Know Your Threat Model

This is the root of most security failures in AI-generated SaaS code. Language models are trained on millions of public repositories. They produce code that compiles, that looks professional, and that handles the happy path correctly. What they don't have is any knowledge of your specific threat model, who your users are, what data you're handling, or what an attacker might target in your particular application.

Veracode's CTO put it plainly: LLMs make the wrong security choices nearly half the time, and it's not getting better.

The failure patterns are predictable. AI skips null checks and input validation. It implements authentication logic on the client side where it can be bypassed. It writes error messages that expose internal logic. It reaches for the shortest path to a working result, and the shortest path is usually the insecure one. Knowing this shapes how you should review and test AI output, and what you should never skip.

Authentication: Where Most AI-Generated Code Gets Compromised First

Authentication is the area where AI-generated SaaS apps fail most visibly and most catastrophically. The AI will produce authentication code that looks complete. It is often not.

Tokens must be properly hashed and have lifecycle management. AI-scaffolded apps routinely skip token hashing and expiry rules. There's frequently no audit trail for who authenticated when, no mechanism to revoke sessions, and no rate limiting on login attempts.

Two-factor authentication, magic links, and password reset flows each introduce their own attack surfaces. Each needs to be treated as a distinct security boundary, not just an implementation detail.

OAuth flows are particularly risky to generate from scratch. The edge cases around state parameter validation, redirect URI matching, and token exchange are subtle enough that even experienced developers get them wrong. If you're building on a boilerplate, understand what authentication the foundation provides before layering anything on top of it. The Two Cents Software Stack ships with five authentication methods, token lifecycle management, audit logging, and security best practices handled correctly so you don't have to solve them in a vibe session.

Secrets Don't Belong in Code (and AI Keeps Putting Them There)

This one is blunt: AI models hardcode API keys, database credentials, and tokens directly into source code. This is one of the most consistently documented failure patterns in AI-generated code.

GitGuardian's 2024 report found 12.8 million secrets leaked on public GitHub, a 28% increase year over year. AI-generated code accelerates this problem. The model optimizes for something that works immediately, not something that's safe to commit.

The fix is mechanical but needs to be habitual. Every secret must live in environment variables or a secrets manager. Your .gitignore must exclude .env files before your first commit, not after. Enable secret scanning on your repository: GitHub's built-in secret scanning and tools like Gitleaks will catch API keys, tokens, and credentials before they reach your remote.

If you're using agentic tools like Claude Code that can write files autonomously, never let the agent run in a mode where it can commit directly without your review. Every file write is a potential accidental exposure.

Slopsquatting: The Supply Chain Attack You Haven't Heard Of Yet

This one is new enough that most developers building with AI tools have never considered it.

AI models hallucinate package names. When you ask a coding assistant to add a library for JWT handling, rate limiting, or file parsing, it sometimes invents a package name that sounds completely legitimate but doesn't exist in npm or PyPI. Research published at USENIX Security 2025 analyzed 576,000 Python and JavaScript code samples across 16 models and found that roughly 20% of recommended packages didn't exist. With commercial models like GPT-4, the hallucination rate was around 5%, which is still substantial at scale.

Here's where it turns dangerous: attackers monitor what package names AI models commonly hallucinate, then register those exact names on PyPI and npm with malicious payloads embedded. The post-install script runs, your credentials get exfiltrated, and nothing in your terminal indicated anything was wrong. Security researcher Seth Larson coined the term "slopsquatting" for this attack, and it's already happening. One hallucinated package accumulated over 30,000 installs before anyone caught it.

The mitigations are practical. Never blindly install packages suggested by AI without verifying they exist and have a meaningful history on the registry. Lockfiles and hash verification pin packages to known, trusted versions. Software Composition Analysis (SCA) tools like Snyk and Aikido SafeChain scan your full dependency tree, catching buried malicious packages that won't surface in your package.json.

If you're running agentic tools with the ability to install packages autonomously, scope those permissions aggressively.

Broken Access Control: The OWASP #1 for a Reason

Broken access control has been the top entry in the OWASP Top 10 for multiple cycles. AI-generated code is particularly prone to it.

The core problem is that AI implements authorization logic inconsistently. It may check permissions correctly in one route and skip the check entirely in another. It frequently places authorization logic on the frontend, where it can be modified by any user with browser developer tools. It doesn't understand your multi-tenant architecture, so user A can often access user B's data if someone knows what URL to request.

Every API endpoint needs server-side authorization checks. Frontend visibility controls are not security controls. A hidden button is not an access restriction.

Multi-tenant data isolation needs explicit testing. Your workspace-scoped queries must include the workspace identifier as a filter, and that filter must come from the authenticated session, never from a user-supplied parameter. The vibe coding + boilerplate breakdown covers why this is one of the most compelling reasons to start with production-ready multi-tenancy infrastructure rather than generating it.

Privilege escalation paths increase dramatically in AI-assisted codebases. Apiiro's research across Fortune 50 enterprises found 322% more privilege escalation paths in AI-generated code compared to human-written equivalents.

Injection Attacks Still Work, and AI Often Leaves the Door Open

SQL injection and cross-site scripting remain relevant. Veracode found that AI-generated code failed to defend against XSS in 86% of cases and against log injection in 88% of cases.

The AI produces code that works with valid inputs. It often doesn't sanitize invalid ones. User-supplied content that flows into database queries, HTML output, or log statements needs explicit validation and encoding. Your ORM provides parameterized queries; use them. Never concatenate user input into a query string regardless of what the AI generates.

Log injection deserves specific mention because it's less commonly checked. If user-supplied strings reach your logging layer without sanitization, an attacker can inject fake log entries, potentially concealing their activity or confusing incident response.

Prompt Injection: A New Attack Surface for AI-Powered Features

If your SaaS product includes any AI-powered features, you're exposed to a class of vulnerability that didn't exist three years ago.

Prompt injection occurs when user-supplied content manipulates an AI component's behavior. A January 2025 demonstration showed attackers embedding malicious instructions in publicly accessible documents. When an enterprise RAG system retrieved those documents, the AI leaked business intelligence, modified its own system prompts to disable safety filters, and executed API calls with elevated privileges. The system treated retrieved content as equally trustworthy as internal instructions.

For SaaS builders, the practical implications are significant. Any AI feature that processes user content, reads external URLs, or queries a knowledge base is a potential injection surface. Treat all externally sourced content as untrusted data. Keep your AI components' permissions minimal. Never give an AI agent more API access than it needs for its specific task.

The same concern extends to your development environment. CVE-2025-54135 allowed attackers to execute arbitrary commands on a developer's machine through Cursor simply by having an active MCP server connected. CVE-2025-53109 allowed arbitrary file reads and writes through Anthropic's file MCP server. If you're using MCP servers in your development workflow, connect only to trusted ones and monitor them for changes.

Security Misconfiguration: The Gap Between Dev and Production

Security misconfiguration moved up to second place in the OWASP Top 10 for 2025. It's also where the gap between a development environment and a production deployment is most dangerous.

AI-generated infrastructure configurations and deployment scripts frequently ship with debug modes enabled, default credentials, over-permissive IAM policies, and exposed admin interfaces. The AI copies permissive examples from training data because they're common in public repositories. The model has no way to know that "*" in a CORS policy or an S3 bucket set to public access is a production disaster.

Before deployment: validate every configuration value explicitly. Your .env.production file must be audited line by line. Debug endpoints must be disabled. CORS policies must be scoped to your actual domains. Default database credentials must be rotated.

Testing AI-generated code properly covers how static analysis (SAST) tools in your CI pipeline catch elevated vulnerability rates before code reaches review. This isn't optional when 45% of your generated code may contain OWASP Top 10 issues.

What Actually Gets Caught (and What Doesn't)

The tools that exist to catch these problems are mature and largely free to integrate.

Static Application Security Testing (SAST): Tools like Semgrep, CodeQL, and Snyk Code run in your CI pipeline and flag common vulnerability patterns before merge. They won't catch everything, but they will catch the predictable failures: hardcoded secrets, SQL injection patterns, insecure deserialization.

Software Composition Analysis (SCA): Scans your dependency tree for known CVEs. This should run on every dependency update, especially if you're using AI tools that introduce packages you didn't explicitly choose.

Secret scanning: GitHub's native secret scanning and Gitleaks both run as pre-commit hooks or CI checks. Enable them immediately. Catching a leaked secret before it reaches the remote is vastly less painful than rotating credentials after an exposure.

Dependency lockfiles: Commit your lockfile. Pin your packages. Hash verification confirms you're installing exactly what you intended.

What these tools don't catch is architectural risk: broken access control across your application, authorization logic scattered inconsistently across routes, multi-tenant data isolation failures. Those require human review with specific knowledge of what AI code tends to get wrong. The AI coding tools comparison notes that the winning teams in AI-assisted development use AI review tools in addition to AI generation, creating a feedback loop where the elevated bug rate gets caught before it hits production.

The Honest Assessment

Using AI coding tools to build a SaaS product is genuinely faster. The security tradeoffs are also real.

The answer isn't to avoid AI-assisted development. It's to be precise about where AI is reliable and where it's not. AI is excellent at generating the feature code you need to differentiate your product. It is consistently unreliable at securing that code without explicit guidance. The infrastructure your product runs on, including authentication, authorization, multi-tenancy, and payment processing, should never be generated from scratch in a vibe session.

Starting with a production-ready foundation that handles these correctly gives your AI tools something solid to build on. The Two Cents Software Stack ships with properly implemented authentication, workspace-scoped multi-tenancy, session management, and security audit logging. Your AI coding sessions then extend that foundation rather than generate it from nothing.

The checklist is a start. The mindset shift is treating AI-generated code as code that needs security review, not code that ships because it ran without errors.