Claude Code Security: How AI-Generated Code Compares to WordPress, Webflow, and Lovable
Key Takeaways
- 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
- 02. Lovable, Bolt, and Cursor produce sites where 53% of code has security holes and zero apps set security headers out of the box
- 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
- 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:
| Platform | Vulnerability Source | Update Model | Developer Control | Security Baseline |
|---|---|---|---|---|
| WordPress | Plugin ecosystem (96% of CVEs) | Manual, per-plugin | Full | Low without active maintenance |
| Webflow | Custom embed code only | Automatic (platform) | Limited | High by default |
| Lovable/Bolt | All generated code, no review | Automatic (platform) | None | Very low |
| Claude Code | Generated code + dependencies | Manual | Full | Variable — 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:
- Verify it exists on npmjs.com
- Check the package’s GitHub repository — zero stars and no commits are red flags
- Review
package.jsonfor unexpectedpostinstallscripts before runningnpm install - Run
npm auditimmediately 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 auditafter everynpm 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
| Factor | WordPress | Webflow | Lovable / Bolt | Claude Code (no process) | Claude Code (with process) |
|---|---|---|---|---|---|
| Vulnerability source | Plugin ecosystem | Custom embeds | All generated code | Generated code + deps | Managed by CLAUDE.md + tooling |
| Update responsibility | Site owner | Webflow | Platform | Developer | Developer |
| Security headers | Manual | Automatic (partial) | None | None by default | Enforced via nginx config |
| Dependency auditing | Manual | Not applicable | None | Manual | Automated via CI |
| XSS protection | Plugin-dependent | Webflow handles | None in 100% of tested apps | 14% miss rate | Caught by Semgrep + CSP |
| IDOR protection | Plugin-dependent | Not applicable | Not present | Inconsistent | Ownership middleware pattern |
| Attack surface | Cumulative, grows with plugins | Minimal, managed | High, ungoverned | Bounded, developer-controlled | Bounded, systematically reduced |
| Ongoing maintenance | High — constant plugin updates | Low | Low | Low | Low |
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
- Veracode 2025 GenAI Code Security Report
- Vibe Coding Security — 69 Vulnerabilities Across 5 Tools — Awesome Agents
- Vibe Coding Security Risks: 53% of AI Code Has Security Holes — Autonoma
- Patchstack 2025 Mid-Year WordPress Vulnerability Report
- Webflow vs WordPress Security — Broworks
- Is Webflow Secure? — BRIX Templates
- CVE-2025-59536 / CVE-2026-21852: RCE via Claude Code — Check Point Research
- CVE-2026-33068: Auth Bypass — SentinelOne
- Claude Code Source Leak — Zscaler ThreatLabz
- 4x Velocity, 10x Vulnerabilities — Apiiro
- AI Code Does Not Mean Secure Code — The Register
- OWASP Top 10:2025
- Finding Vulnerabilities Using Claude Code — Semgrep
- Constitutional Classifiers — Anthropic
- CSET: Cybersecurity Risks of AI-Generated Code — Georgetown University
- OpenSSF Security Guide for AI Code Assistants
Frequently Asked Questions
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 ↗