I Scanned a Sample AI-Style SaaS App. Here's What It Found.

It's a familiar pattern: someone posts “I built this with Cursor in a weekend!” — and later, some of those apps turn out to have security holes. I built a tool to catch them — and used it to see what the problem looks like in practice.

The Problem Nobody Talks About

AI coding tools are incredible. Cursor, Lovable, Bolt, Replit — they can build a full SaaS app in hours. But there's a catch that the “vibe coding” community doesn't like to discuss: AI-generated code is consistently insecure.

A 2025 Veracode study found that 45% of AI-generated code samples failed its security tests, introducing OWASP Top 10 vulnerabilities.

The Experiment

I created a realistic AI-generated SaaS app — the kind of code Cursor or Bolt would produce for a typical startup. Express backend, Supabase database, Stripe payments, user authentication. About 47 files.

Then I scanned it with XploitScan, running all 131 security rules it had at the time.

The Results

Editor's note: an earlier version of this post quoted exact finding counts and a grade for this scan. We removed them because we can't reproduce that run. The categories below are what fired.

Hardcoded Secrets

API keys, database credentials, and encryption keys directly in the source code. Anyone who can see your code (or your git history) can steal these.

What AI gets wrong: AI tools often hardcode credentials because that's what they were trained on. They don't always separate secrets into environment variables.

Injection Vulnerabilities

SQL injection, XSS, and command injection. Classic web app vulnerabilities that have existed for 20+ years — and AI tools still produce them.

Configuration Issues

CORS set to allow all origins, missing security headers, debug mode in production, no rate limiting on login endpoints. These are the “I didn't know I needed to do that” issues.

Why this matters: AI tools build features, not security controls. They'll create a login endpoint but won't add rate limiting to prevent brute-force attacks.

Missing Payment Security

Stripe webhook endpoints without signature verification. Anyone can send fake payment events to your app, marking orders as paid without actually paying. This one finding alone could cost a business thousands of dollars.

The Compliance Impact

Findings like these map to compliance frameworks such as SOC2, ISO 27001 and the OWASP Top 10. If you're building a B2B SaaS and your customers ask about SOC2 or ISO 27001, these issues need to be fixed first.

What You Should Do

1. Scan your code before you deploy. You can do this for free at xploitscan.com — paste code or upload a single file, no signup required (a free account adds multi-file and ZIP uploads).
2. Never hardcode secrets. Use environment variables. Always. Check your git history too — if secrets were ever committed, they're still there.
3. Add authentication to every API route. AI tools often create routes without auth checks. Every endpoint that reads or writes user data needs verification.
4. Verify payment webhooks. If you use Stripe, always verify the signature with stripe.webhooks.constructEvent().
5. Don't trust AI-generated security code. AI tools are great at features but consistently bad at security. Treat every AI-generated app as if it has vulnerabilities — because it probably does.

Try It Yourself

See what XploitScan finds in your code:

• Web: xploitscan.com/scan — paste code or upload a file, no signup
• CLI: npx xploitscan@latest scan . runs locally. Your files are only sent out if you set ANTHROPIC_API_KEY, in which case they go to Anthropic for AI analysis. If you sign in, findings with short code excerpts sync to your dashboard. Dependency names and versions are checked against OSV.dev.
• See an example first: xploitscan.com/demo