We Scanned 100 AI-Built Apps for Security Flaws.
Here's What We Found.

AI-assisted development has made it possible to go from an idea to a working application in hours. But there's a problem.

Tools such as Cursor, Lovable, Bolt, v0, Replit and Windsurf can help developers build incredibly quickly. That doesn't necessarily mean the resulting application is ready to face the internet.

We analysed 100 AI-built applications to find out what security problems were making it into real projects. The results suggest a growing gap between “The app works” and “The app is safe to launch.”

We wanted to understand the security risks appearing in applications created using modern AI-assisted development workflows. So we analysed 100 applications built primarily using AI coding tools.

These weren't deliberately vulnerable applications or cybersecurity challenges. They were the kind of projects people are building every day: SaaS products, internal tools, dashboards, marketplaces, directories, AI wrappers, productivity applications and early-stage startup products.

We weren't searching for obscure theoretical vulnerabilities. We focused on mistakes capable of creating real-world exposure when an application reaches production. Things like:

• Exposed API keys and credentials
• Missing database access controls
• Authentication and authorisation weaknesses
• Insecure API routes
• Sensitive information exposed client-side
• Overly permissive database configuration
• Unsafe environment handling
• Missing security headers
• Dependency vulnerabilities
• Endpoints trusting user-controlled input

Each application was analysed using the same security assessment methodology. What we found was concerning.

This distinction appeared repeatedly during the research.

An application can have perfectly functioning authentication and still contain serious authorisation vulnerabilities. The developer sees a login screen, the dashboard is protected, unauthenticated visitors are redirected — everything appears secure. But a logged-in user may still be able to access another user's resources.

For example: the user must be logged in ✓ — but there's no check that the requested record belongs to them ✗.

This is exactly the type of vulnerability that can survive normal application testing because developers generally test whether legitimate actions work. Attackers test whether illegitimate actions work too.

Client-Side Trust Was Another Recurring Problem

We also found applications relying too heavily on the browser to enforce security decisions. For example:

if (user.role === "admin") {
    showAdminPanel();
}

Hiding an admin button is useful for the interface. It is not an access-control mechanism. The underlying API or server action still needs to verify that the requesting user has permission to perform the operation. Anything running in the user's browser should be treated as potentially controllable by that user. Security-sensitive decisions belong on the server.

AI Can Generate Secure Code. That's Not the Problem.

The conclusion from this research isn't that AI-generated code is inherently insecure. Modern coding models can recognise vulnerabilities, recommend security controls and produce secure implementations.

The problem is the development workflow. A typical vibe-coding conversation looks like:

Every instruction is focused on functionality. Unless security is deliberately included in that process, it is surprisingly easy for it to become an afterthought. AI optimises against the requirements it's given. If the requirement is “Make this work”, that's what gets tested — not “Make this safe when someone deliberately tries to break it.”

Why These Problems Survive Until Production

Traditional software teams often have developer → code review → QA → security tooling → staging → production. A solo AI-assisted founder might have: Founder + AI → Production.

That's part of what makes vibe coding so powerful. It's also why a new safety net is needed. The person building the application may be simultaneously acting as founder, developer, designer, QA engineer, DevOps engineer, and security reviewer — and may have only started programming recently. That isn't a criticism. It's a consequence of software development becoming accessible to dramatically more people. Security tooling needs to become equally accessible.

The “It Works” Trap

One of the biggest lessons from analysing these applications was how normal insecure software can look. A vulnerable application doesn't necessarily crash, display an error, run slowly, look unfinished, or fail its tests. It can look fantastic. The authentication works. Stripe works. The database works. The animations work. The application deploys successfully. And the vulnerability is still there.

That's what makes security mistakes fundamentally different from many normal bugs. A broken button announces itself. A missing authorisation check doesn't.

Vibecheck is a security scanner designed specifically around the way AI-assisted applications are being built. Connect your repository and Vibecheck looks for security issues that are easy to miss when you're moving quickly. But the important part isn't simply producing a list of warnings — Vibecheck is designed to explain what's wrong, why it matters, how serious it is, and what to change. Because a security report isn't much use to a vibe coder if understanding it requires being a security engineer.