/shvchk
AI April 6, 2026 · 14 min read

Claude Code Security: How AI-Generated Code Compares to WordPress, Webflow, and Lovable

#ai#security#claude-code#web-development#webflow#wordpress#lovable

Key Takeaways

  1. 01. WordPress has 64,782 tracked vulnerabilities and accounts for 90% of hacked CMS sites — the baseline most clients forget when evaluating AI-built sites
  2. 02. Lovable, Bolt, and Cursor produce sites where 53% of code has security holes and zero apps set security headers out of the box
  3. 03. Claude Code with a defined security process consistently outperforms vibe-coding tools and rivals Webflow in practice — but only with the process in place
  4. 04. The fix stack (CLAUDE.md rules + Semgrep + OWASP ZAP + WAF) closes 95%+ of documented attack vectors before production

The question is not “is AI-generated code secure?” The question is: compared to what?

WordPress powers 43% of the web and accounts for 90% of hacked CMS sites. Webflow is hosted on AWS with SOC 2 Type II certification. Lovable and Bolt produce apps where zero sites set security headers by default. Claude Code sits somewhere in this landscape — and where exactly depends on the process around it.

This article maps that landscape with data.


Part 1: The Security Baseline — What You’re Comparing Against

Before evaluating Claude Code, it helps to understand what “normal” looks like for website security across the industry.

WordPress — The Industry Default

WordPress runs 43% of all websites globally. Its security record:

  • 64,782 tracked vulnerabilities across the WordPress ecosystem as of 2026
  • 6,700+ new vulnerabilities discovered in the first half of 2025 alone
  • 96% of vulnerabilities are in plugins, 4% in themes — WordPress core itself is relatively secure
  • 90% of hacked CMS sites are WordPress
  • 87.8% of real-world WordPress exploits bypass standard hosting-level protections in controlled tests

The core WordPress software is not the problem. The plugin ecosystem is. Every plugin is a potential attack surface maintained by a third party with varying security practices. The average WordPress site has 20+ plugins installed. That’s 20+ surfaces to keep updated, audit, and monitor indefinitely.

Webflow — The Managed Alternative

Webflow represents the opposite architectural choice: a closed, managed platform.

  • No plugin ecosystem — eliminates the #1 source of WordPress vulnerabilities
  • Managed hosting on AWS + Fastly CDN with automatic updates
  • SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018 certifications
  • Security patching is Webflow’s responsibility, not the site owner’s
  • Custom code added via embeds introduces standard web vulnerabilities — that part is still the developer’s responsibility

The tradeoff: Webflow’s security is strong by default but you are limited to what Webflow’s platform allows. Complex custom functionality requires workarounds or external services, each of which reintroduces risk.

Lovable, Bolt, Cursor — The Vibe Coding Tools

The newest category. These tools generate full applications from natural language prompts with minimal developer oversight.

Security research on 5,600 vibe-coded applications (2025-2026):

  • 53% of AI-generated vibe-coded apps contain security holes
  • 2,000+ vulnerabilities found across the sample
  • 400+ exposed secrets — API keys, database credentials in client-side code
  • 175 instances of exposed PII — user data accessible without authentication

In a Tenzai security test across 15 apps built with Lovable, Bolt, Cursor, and Replit:

  • Every single app introduced SSRF (Server-Side Request Forgery) vulnerabilities
  • Zero apps implemented CSRF protection
  • Zero apps set security headers

The most documented consequence: Enrichlead, a B2B startup with 100% Cursor-generated code, was shut down days after launch when security researchers found it riddled with entry-level vulnerabilities. The founders attempted to fix the issues using the same AI tools — and couldn’t bring the codebase to an acceptable security standard.

Platform-specific failure modes:

  • Lovable: regularly disables Row Level Security (RLS) on Supabase tables, exposes Supabase configuration in frontend code
  • Bolt: missing authentication on API routes, no rate limiting on any endpoints
  • Cursor: generates correct-looking code that skips ownership checks (IDOR)

Part 2: Where Claude Code Sits in This Landscape

Claude Code is a fundamentally different category from Lovable or Bolt. It is a development tool used by developers — not a no-code platform that generates and deploys automatically. This distinction matters for security.

The comparison matrix:

PlatformVulnerability SourceUpdate ModelDeveloper ControlSecurity Baseline
WordPressPlugin ecosystem (96% of CVEs)Manual, per-pluginFullLow without active maintenance
WebflowCustom embed code onlyAutomatic (platform)LimitedHigh by default
Lovable/BoltAll generated code, no reviewAutomatic (platform)NoneVery low
Claude CodeGenerated code + dependenciesManualFullVariable — depends on process

Claude Code occupies the “full developer control” quadrant — which means its security ceiling is high and its floor can be low. The process determines where the outcome lands.

What the Research Shows

Veracode GenAI Code Security Report (2025) — tested 100+ LLMs including Claude across 80 coding tasks:

  • 45% of AI-generated code contains OWASP Top 10 vulnerabilities
  • XSS: 86% failure rate across all models tested
  • SQL Injection: 20% failure rate (80% pass rate)

Georgia Tech Vibe Security Radar (2026):

  • 27 of 35 March 2026 CVEs were attributed to Claude Code-generated code
  • Total AI-generated CVEs grew from 6 in January to 35 in March — a 5.8x increase in two months

Apiiro (Fortune 50 enterprises):

  • CVSS 7.0+ vulnerabilities appear 2.5x more in AI-generated code than human-written
  • Privilege escalation paths: +322%, design flaws: +153%

The honest read: Claude Code generates code with real, consistent vulnerability patterns. XSS is the most common failure. But compared to Lovable/Bolt where zero apps set security headers, Claude Code with a defined process performs significantly better — and the vulnerabilities it introduces are detectable and fixable at build time.


Part 3: Real CVEs — What Happened and What Was Fixed

CVE-2025-59536 and CVE-2026-21852 — RCE in the Tool Itself

Researcher: Check Point Research | Severity: Critical

These vulnerabilities are in Claude Code the development tool, not in websites it builds. A malicious Git repository could execute arbitrary shell commands on a developer’s machine and steal Anthropic API credentials when a developer opened the repository.

Impact on client websites: Indirect — if a developer’s machine is compromised, deployment credentials may be at risk. The production site itself is unaffected by the vulnerability directly.

Status: Patched. Anthropic added enhanced warning dialogs for untrusted Claude Code configurations.

CVE-2026-33068 — Authentication Bypass in Workspace Trust

Researcher: SentinelOne | Severity: High

Malicious repositories could bypass workspace trust dialogs — Claude Code’s permission system. Again, this targets the developer environment, not the generated code.

Status: Patched.

The Source Code Leak (March 31, 2026)

Anthropic accidentally published a 59.8 MB JavaScript source map for Claude Code v2.1.88 to npm — exposing ~512,000 lines of TypeScript source. This accelerated CVE discovery by giving researchers full visibility into the implementation.

The incident was significant not because of what was in the source (no user data was exposed) but because it shortened the time from vulnerability existence to vulnerability discovery. All resulting CVEs have since been patched.


Part 4: Common Vulnerability Patterns and How to Fix Them

This is where the actionable part of the research lives. Each vulnerability pattern Claude Code commonly introduces has a standard, well-understood fix.

XSS — Fix Rate: Immediate with DOMPurify

The most common failure (86% of cases in Veracode testing). The pattern:

// What Claude Code generates
element.innerHTML = userInput;

// What it should generate
element.textContent = userInput;
// Or when HTML rendering is required:
element.innerHTML = DOMPurify.sanitize(userInput);

Systematic fix: Add a Content Security Policy header that blocks inline script execution. This makes XSS attacks non-executable even if the vulnerable code exists:

add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none';";

CSP is a defense-in-depth measure — it does not replace sanitization, but it means a missed sanitization does not automatically become a working exploit.

SQL Injection — Fix: Parameterized Queries

# What Claude Code may generate
query = f"SELECT * FROM users WHERE email = '{email}'"

# The fix — parameterized query, no string interpolation
cursor.execute("SELECT * FROM users WHERE email = ?", (email,))

For ORM users: every major ORM (Sequelize, Prisma, SQLAlchemy, ActiveRecord) handles parameterization automatically when using their query builder methods. The vulnerability only appears when developers drop to raw SQL strings — which Claude Code sometimes does for complex queries.

Catch it automatically: Semgrep’s p/sql-injection ruleset flags string interpolation in SQL contexts:

semgrep --config=p/sql-injection .

Package Hallucination — Fix: Verification Before Install

Claude Code may suggest npm packages that do not exist. Before installing any AI-suggested package:

  1. Verify it exists on npmjs.com
  2. Check the package’s GitHub repository — zero stars and no commits are red flags
  3. Review package.json for unexpected postinstall scripts before running npm install
  4. Run npm audit immediately after installation
npm audit --audit-level=high

IDOR — Fix: Ownership Verification Middleware

// What Claude Code generates (checks existence, not ownership)
app.get('/document/:id', async (req, res) => {
  const doc = await db.find(req.params.id);
  res.json(doc);
});

// The fix — ownership middleware applied to all resource routes
const requireOwnership = async (req, res, next) => {
  const resource = await db.find(req.params.id);
  if (!resource || resource.ownerId !== req.user.id) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  req.resource = resource;
  next();
};

app.get('/document/:id', requireOwnership, (req, res) => {
  res.json(req.resource);
});

The middleware pattern is important: it centralizes ownership logic so it cannot be forgotten on individual routes.

Hardcoded Secrets — Fix: Environment Variables + Secret Scanning

// What Claude Code may generate in examples
const apiKey = "sk-1234567890abcdef";

// The fix
const apiKey = process.env.API_KEY;
// And in .env (never committed to git):
// API_KEY=sk-1234567890abcdef

Automated detection with git-secrets or truffleHog in the pre-commit hook:

# .git/hooks/pre-commit
git-secrets --scan

If a secret was already committed: rotate it immediately (assume it’s compromised), then use git filter-branch or BFG Repo Cleaner to remove it from history.


Part 5: The 4-Layer Defense System

This is the process that closes the gap between Claude Code’s default output and production-ready security.

Layer 1: CLAUDE.md — Guardrails at the Source

A CLAUDE.md file committed to the repository root. Claude Code reads this file before generating any code for the project. It functions as mandatory security rules that override Claude’s default behavior:

# Security Requirements — Claude reads this before generating code

## Required in every component:
- User input rendered to DOM: use textContent or DOMPurify.sanitize(), never innerHTML
- Database queries: parameterized statements only, no string interpolation
- Resource endpoints: ownership verification middleware on every route
- Credentials: process.env only, never inline, never in examples

## Dependency rules:
- Verify every suggested package exists on npmjs.com before suggesting it
- Flag any package with postinstall scripts for human review
- Prefer packages with >1000 weekly downloads and active maintenance

## Required in every API response:
- Content-Security-Policy header
- X-Frame-Options: DENY
- X-Content-Type-Options: nosniff

This single file changes the distribution of what Claude Code generates. It does not eliminate all issues but shifts the baseline significantly.

Layer 2: Development Workflow

  • npm audit after every npm install — flags packages with known CVEs before they enter the codebase
  • Manual review of all Claude-generated code touching: authentication, file uploads, database queries, external API calls
  • Semgrep scan on every pull request — catches injection patterns, secret exposure, and insecure function calls
# Run in CI pipeline
semgrep --config=p/owasp-top-ten --config=p/nodejs-security --error .

Layer 3: Pre-Deployment Testing

OWASP ZAP (free, open source) — dynamic testing that simulates real attacks against a staging environment. Catches runtime issues that static analysis misses:

docker run -t owasp/zap2docker-stable zap-baseline.py -t https://staging.yoursite.com

Dependency-Check — scans all packages against the NVD CVE database:

dependency-check --project "site" --scan . --format HTML --out ./security-report

Layer 4: Production Server Configuration

# Required security headers
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'none'";
add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
add_header Referrer-Policy "strict-origin-when-cross-origin";
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()";

WAF: Cloudflare Free tier provides WAF rules that block automated SQL injection scanners, XSS probes, and path traversal attempts before they reach the application. This layer catches attack patterns that application-level validation misses.

Rate limiting on all form endpoints and authentication routes — prevents brute force and automated vulnerability scanning.


Part 6: Platform Security Comparison — The Real Picture

FactorWordPressWebflowLovable / BoltClaude Code (no process)Claude Code (with process)
Vulnerability sourcePlugin ecosystemCustom embedsAll generated codeGenerated code + depsManaged by CLAUDE.md + tooling
Update responsibilitySite ownerWebflowPlatformDeveloperDeveloper
Security headersManualAutomatic (partial)NoneNone by defaultEnforced via nginx config
Dependency auditingManualNot applicableNoneManualAutomated via CI
XSS protectionPlugin-dependentWebflow handlesNone in 100% of tested apps14% miss rateCaught by Semgrep + CSP
IDOR protectionPlugin-dependentNot applicableNot presentInconsistentOwnership middleware pattern
Attack surfaceCumulative, grows with pluginsMinimal, managedHigh, ungovernedBounded, developer-controlledBounded, systematically reduced
Ongoing maintenanceHigh — constant plugin updatesLowLowLowLow

The key insight in this table: WordPress’s attack surface grows continuously as the plugin ecosystem evolves. Webflow’s is managed by a third party. Lovable/Bolt’s is high and ungoverned. Claude Code’s is bounded — the code it generates is the code it generates, and all of it can be audited at build time.

A WordPress site that was secure in 2024 may not be secure in 2026 because a plugin it depends on introduced a new CVE. A Claude Code-built site that passed security review at launch does not automatically inherit new vulnerabilities from ongoing platform changes — unless its dependencies are updated without review.


Part 7: Conclusion

The security question for any website comes down to: what is the ongoing attack surface and who is responsible for managing it?

WordPress hands that responsibility to the site owner indefinitely, with 6,700+ new plugin vulnerabilities per year to track. Webflow takes the responsibility away from the developer — at the cost of flexibility. Lovable and Bolt generate sites with structural security gaps that are difficult to fix after the fact.

Claude Code, with deliberate process, produces a bounded, auditable codebase. The vulnerabilities it introduces are systematic — which means they can be found systematically. The tools to find them are free (Semgrep, OWASP ZAP, npm audit). The fixes are documented and standard.

The formula:

Claude Code + CLAUDE.md rules + Semgrep/OWASP ZAP + WAF = security posture that exceeds default WordPress, equals managed Webflow, and significantly outperforms all vibe-coding platforms

The condition: the process has to be in place from the start. Claude Code without process produces output closer to Lovable or Bolt than to Webflow. Claude Code with process produces output that a security auditor can review, verify, and sign off on.

That is a defensible foundation for any client site.


Sources

Frequently Asked Questions

B

Written by

Bohdan Shvchk

Founder & Shopify and Webflow Developer

5+ years building on Webflow, 2+ years on Shopify. Previously at a digital agency. Obsessed with performance and clean architecture.

LinkedIn ↗