Your AI-Built App vs. a Real Attacker: What Actually Happens

A typical vibe-coded SaaS application can be fully compromised by an attacker in under 60 minutes. The attack path follows a predictable pattern: reconnaissance (minutes 0-5), finding exposed configuration files (5-15), dumping the database (15-30), accessing payment systems (30-45) and planting a backdoor (45-60). None of this requires advanced hacking skills. Sherlock Forensics performs penetration tests on AI-built apps to find these vulnerabilities before attackers do, starting at $1,500.

This Is Not a Hypothetical

What follows is a composite attack narrative based on real penetration tests we have conducted at Sherlock Forensics against vibe-coded applications. The names and details are changed. The vulnerabilities are real. The timeline is realistic. And the point is this: nothing in this attack requires sophistication.

The target is a SaaS application built by a non-technical founder using AI coding tools. It has a login page, user profiles, a subscription system connected to Stripe and an admin dashboard. It has about 200 users and has been live for three weeks.

Minutes 0-5: Reconnaissance

The attacker does not start by typing in the login form. They start by looking at the application from the outside.

Minute 0: View the page source. The HTML reveals the framework (React, Next.js, Vue), API endpoint patterns and sometimes comments left by the AI tool that generated the code. Comments like <!-- TODO: add authentication check --> are more common than you would think.

Minute 1: Open browser developer tools. Check the Network tab while navigating the app. Watch the API calls. Note the URL patterns: /api/users/42, /api/admin/settings, /api/subscriptions. Each of these is an attack surface.

Minute 2: Check the JavaScript bundle. In a React or Next.js app, the compiled JavaScript often contains API keys, endpoint URLs and even backend logic. The attacker searches the JS files for strings like sk_live (Stripe secret key), supabase, firebase and Bearer.

Minute 3: Check public records. The domain's DNS records, WHOIS data and SSL certificate reveal hosting provider, email addresses and sometimes the founder's name. A search for the founder on GitHub might reveal the project repository if it is public.

Minute 5: The attacker now has a map of the application: the tech stack, API endpoints, potential admin routes and possibly some API keys found in client-side JavaScript. They have not tried a single password or exploited a single bug. They just looked.

Minutes 5-15: Finding the .env File

The attacker runs a directory scanner. This is a tool that requests hundreds of common file paths per second, looking for files that should not be publicly accessible.

Minute 6: The scanner tries /.env. The server returns a 200 OK response. The .env file downloads. It contains:

DATABASE_URL=postgres://admin:p4ssw0rd@db.example.com:5432/myapp
STRIPE_SECRET_KEY=sk_live_51K...
JWT_SECRET=mysupersecretkey123
OPENAI_API_KEY=sk-proj-abc...

Game over? Almost. But the attacker keeps going because there is more to find and more damage to do.

Minute 8: The scanner also finds /.git/config, confirming the git repository is exposed. The attacker uses a tool to reconstruct the entire source code from the .git directory. Now they have every file, every commit and every secret that was ever in the codebase.

Minute 12: The scanner finds /api/admin/users returns a full list of users without requiring authentication. The admin API endpoints have no authorization checks. The AI put a login gate on the /admin frontend page but the backend API serves data to anyone who asks.

In 12 minutes, the attacker has: the database credentials, the Stripe secret key, the JWT secret, the full source code and a list of every user. They have not exploited any complex vulnerability. They have just requested files and URLs.

Minutes 15-30: Dumping the Database

Minute 15: The attacker connects to the database using the credentials from the .env file. If the database is hosted on a service like Supabase, Railway or PlanetScale, the connection string often works from anywhere because the vibe coder never configured IP allowlisting.

Minute 17: The attacker runs a query to list all tables. They find tables for users, subscriptions, invoices and sessions.

Minute 18: They dump the users table. In many vibe-coded apps, passwords are stored in plaintext or with weak hashing (MD5, SHA-1 without salt). If passwords are in plaintext, the attacker has every user's credentials immediately. If they are weakly hashed, a tool like hashcat cracks the majority of them in minutes.

Minute 22: The attacker dumps the entire database. User emails, profile data, subscription details, payment history. Everything the application stores is now in the attacker's hands. This is the part where plaintext password storage becomes catastrophic.

Minute 25: Using the JWT secret from the .env file, the attacker forges a JWT token for any user account. They create an admin token and now have full admin access to the application through the normal interface.

Minutes 30-45: Accessing Stripe

Minute 30: The attacker uses the Stripe secret key from the .env file. With this key, they can list all customers, view payment methods, issue refunds, create charges and access the full transaction history.

Minute 33: They list all customers and their payment information. While Stripe does not expose full card numbers through the API, the attacker can see the last four digits, card brand, expiration date and billing address for every customer.

Minute 35: The attacker could issue refunds to themselves, create new charges or redirect payouts. The financial damage potential is significant. But a sophisticated attacker might not do any of this yet because it would trigger alerts. Instead, they move to the next step.

Minute 40: Using the OpenAI API key, the attacker makes requests to the OpenAI API billed to your account. Depending on the model and volume, this could run up thousands of dollars in charges before anyone notices.

Minutes 45-60: Planting a Backdoor

Minute 45: If the application has file upload functionality (profile pictures, document uploads, attachments), the attacker tests whether it validates file types. In most vibe-coded apps, it does not. The AI implemented file upload by saving whatever the user sends to a publicly accessible directory.

Minute 47: The attacker uploads a web shell disguised as an image. A web shell is a script that gives the attacker command-line access to the server through the browser. Once uploaded, they can execute any command on the server.

Minute 50: With server access, the attacker creates a new admin account through the database, installs a persistent backdoor that survives application restarts and sets up a reverse shell that calls back to their server every hour.

Minute 55: The attacker cleans up access logs, removes evidence of their database queries and ensures their backdoor is hidden in a file that looks like a legitimate part of the application.

Minute 60: The attacker disconnects. They now have persistent access to the server, a copy of the complete database, working API keys for Stripe and OpenAI, the ability to forge authentication tokens for any user and a backdoor they can use to return at any time.

Total time: under one hour. Skill level required: beginner to intermediate. Tools used: all free and publicly available.

This Is the Minimum

This scenario is not a worst case. It is the baseline. This is the minimum set of steps any attacker tries against any web application. There is nothing creative or advanced here. It is a checklist. Automated tools perform most of these steps without human intervention.

The attacker did not need to find a zero-day vulnerability. They did not need to write custom exploit code. They did not need to social engineer anyone. They requested publicly accessible files, connected to a database with exposed credentials and uploaded a file to a directory with no validation. Every single step exploited a vulnerability that is standard in vibe-coded applications.

A penetration test follows the same methodology. The difference is that a pentester documents every finding, rates the severity, explains the business impact and provides step-by-step remediation instructions. Then they verify the fixes actually work. Read about the specific vulnerabilities in vibe-coded login pages and run our 5-minute security checklist to catch the most obvious issues yourself.

What to Do About It

If this scenario sounds familiar, if your app has an exposed .env file or unprotected admin APIs or passwords in a text file, you need to fix those issues immediately. But fixing the ones you know about is not enough. A real audit finds the ones you do not know about.

Sherlock Forensics runs penetration tests specifically for vibe-coded applications. We follow the same attack methodology described above, but we do it thoroughly, document every finding and give you a clear remediation plan. Quick audits start at $1,500. Order online or call 604.229.1994.

Still not sure you need one? Our guide on whether your side project needs a pentest walks through the decision tree.

Frequently Asked Questions

How long does it take to hack a website?

For a typical vibe-coded application, an attacker can achieve significant compromise in under 60 minutes. Exposed configuration files and unprotected API endpoints are the fastest entry points. Automated scanners can identify these vulnerabilities in seconds. The exploitation steps are well documented and require minimal skill.

Can a beginner hacker break into my app?

Yes. The vulnerabilities common in AI-built applications are among the easiest to exploit. Downloading an exposed .env file requires only a browser. Connecting to a database with leaked credentials requires a free client. SQL injection is taught in introductory security courses. None of the steps in the attack scenario above require advanced skills.

What do penetration testers actually do?

Penetration testers simulate the same attack steps a real attacker would use, but in a controlled and authorized engagement. They identify every exploitable vulnerability, document the severity and business impact of each finding and provide detailed remediation steps. At Sherlock Forensics, our testers are CISSP, ISSAP and ISSMP certified with 20+ years of experience. Reports are written in plain language for non-technical founders.