What Is Penetration Testing? Security Testing Your AI-Built App

Why AI Coders Need to Know This

Here's the uncomfortable truth: AI is really good at writing code that works, and really bad at writing code that's secure. When you ask Claude or Cursor to build a login system, it will give you something that authenticates users. But it probably won't rate-limit login attempts. It might store passwords in plain text if you didn't specifically ask for hashing. It could leave debug endpoints exposed. It might accept any input without validation.

These aren't theoretical problems. A 2025 Stanford study found that developers using AI assistants produced code with significantly more security vulnerabilities than those writing code manually — and were more confident their code was secure. That's the worst combination: more holes, less awareness.

Penetration testing is the reality check. It's where you stop trusting that the code "looks right" and actually try to break it. For vibe coders who are shipping real apps to real users, this isn't optional — it's the difference between a side project and a lawsuit.

You don't need to become a security expert. You need to know:

• What penetration testing actually is (and isn't)
• The most common vulnerabilities AI creates
• Free tools that can find the obvious stuff
• How to talk to your AI about fixing what you find
• When to call in a professional

Real Scenario

You asked Claude to build a user registration and login system for your SaaS app. It created a nice form, connected it to a database, added JWT tokens for sessions. Everything works perfectly in testing. Users can sign up, log in, access their dashboard.

Then you run OWASP ZAP against it. Here's what it finds:

• SQL injection on the login form — entering ' OR 1=1 -- as the username bypasses authentication entirely
• No rate limiting — an attacker can try 10,000 passwords per second
• JWT secret is "secret" — the AI used a placeholder and you never changed it
• Password reset sends the actual password in the email — meaning passwords are stored in plain text
• CORS is set to allow all origins — any website can make authenticated requests to your API

Every single one of those is a real vulnerability that AI coding tools routinely create. And every single one would have been invisible if you just clicked around your app and said "looks good."

I just ran OWASP ZAP against my app and found these vulnerabilities:
1. SQL injection on the login form
2. No rate limiting on authentication endpoints
3. JWT secret is hardcoded as "secret"
4. Passwords stored in plain text
5. CORS allows all origins

Fix all five issues. For each one:
- Explain what the vulnerability allows an attacker to do
- Show the current vulnerable code
- Show the fixed code
- Explain why the fix works

Use Express.js with PostgreSQL. Use bcrypt for password hashing and 
a proper JWT secret from environment variables.

What AI Generated

When you ask AI to help with penetration testing, it can actually be quite useful — both for understanding vulnerabilities and for fixing them. Here's what a typical AI response looks like when you report findings:

// BEFORE: Vulnerable login (SQL injection + plain text passwords)
app.post('/login', async (req, res) => {
  const { email, password } = req.body;
  // ❌ String concatenation = SQL injection
  const query = `SELECT * FROM users WHERE email = '${email}' 
                 AND password = '${password}'`;
  const user = await db.query(query);
  // ❌ JWT secret is hardcoded
  const token = jwt.sign({ id: user.id }, 'secret');
  res.json({ token });
});

// AFTER: Fixed login
const bcrypt = require('bcrypt');
const rateLimit = require('express-rate-limit');

// ✅ Rate limiting: max 5 login attempts per 15 minutes per IP
const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 5,
  message: { error: 'Too many login attempts. Try again later.' }
});

app.post('/login', loginLimiter, async (req, res) => {
  const { email, password } = req.body;

  // ✅ Parameterized query prevents SQL injection
  const result = await db.query(
    'SELECT * FROM users WHERE email = $1', 
    [email]
  );
  const user = result.rows[0];
  if (!user) return res.status(401).json({ error: 'Invalid credentials' });

  // ✅ bcrypt.compare checks against the hashed password
  const valid = await bcrypt.compare(password, user.password_hash);
  if (!valid) return res.status(401).json({ error: 'Invalid credentials' });

  // ✅ JWT secret from environment variable
  const token = jwt.sign(
    { id: user.id }, 
    process.env.JWT_SECRET,
    { expiresIn: '24h' }
  );
  res.json({ token });
});

Understanding Each Part

Let's break down what penetration testing actually involves. There are several types, and you don't need all of them right away.

Types of Pen Testing

Black box testing means the tester knows nothing about your app's internals. They approach it like a real attacker would — poking at the login page, trying weird inputs, looking for exposed endpoints. This is the most realistic but also the most time-consuming.

White box testing means the tester has full access to your source code, database schema, and architecture. They can find vulnerabilities faster because they can read the code. For AI-built apps, this is especially valuable because an experienced reviewer can spot AI-generated antipatterns immediately.

Gray box testing is the middle ground — some knowledge, some exploration. This is what most vibe coders will do themselves: you know your own code (sort of), and you run tools against your live app.

The OWASP Top 10 Connection

The OWASP Top 10 is the industry standard list of the most critical web application security risks. When you run a pen test, you're basically checking your app against this list. AI-built apps are especially vulnerable to:

• A03: Injection — SQL injection, command injection, XSS. AI loves string concatenation.
• A01: Broken Access Control — Users can access other users' data. AI often doesn't implement proper authorization checks.
• A07: Authentication Failures — Weak passwords, no rate limiting, exposed tokens.
• A05: Security Misconfiguration — Debug mode on, default credentials, permissive CSP headers.
• A02: Cryptographic Failures — Plain text passwords, weak encryption, hardcoded API keys.

Free Tools You Can Use Today

You don't need to spend thousands on professional pen testing to find the obvious stuff. These free tools catch the most common vulnerabilities:

OWASP ZAP (Zed Attack Proxy) — The gold standard for free web app security testing. Point it at your app and it will spider through every page, try common attack payloads, and generate a report of everything it finds. It's like having a junior security tester that works for free and never gets tired.

Burp Suite Community Edition — The professional pen tester's tool with a free tier. It intercepts requests between your browser and your app, letting you modify them to test for vulnerabilities. More manual than ZAP but more powerful for targeted testing.

Nikto — A web server scanner that checks for known dangerous files, outdated software, and misconfigurations. Quick to run, good for catching the low-hanging fruit.

SQLMap — Specifically for finding and exploiting SQL injection. If your AI-built app uses a database (and it probably does), run SQLMap against your forms and API endpoints.

npm audit / Snyk — Not pen testing tools per se, but dependency scanning catches known vulnerabilities in your packages. AI loves pulling in dependencies, and those dependencies have CVEs.

What AI Gets Wrong About Penetration Testing

When you ask AI for security advice, watch out for these common failures:

"Just add helmet.js and you're secure." Helmet sets HTTP security headers, which is good. But it doesn't fix SQL injection, broken authentication, or business logic flaws. It's like putting a lock on the front door while leaving the windows open. AI often suggests security middleware as if it's a complete solution.

AI generates "security theater" code. It'll add input validation that checks if an email "looks like an email" but still concatenates it directly into a SQL query. The validation makes you feel secure without actually preventing the attack. Always trace the data flow from input to database — not just the validation step.

AI assumes you'll handle secrets correctly. When AI generates code with process.env.JWT_SECRET, it assumes you'll actually set that environment variable to something strong. Many vibe coders see that, don't know what it means, and either hardcode a simple string or skip it. The AI won't tell you to generate a 256-bit random secret. You need to know to ask. See our guide on secrets management.

AI doesn't test its own code. This is the fundamental gap. AI can generate a login system in 30 seconds. It cannot then turn around and try to hack that login system to see if it actually holds up. That's your job, or the pen tester's job. The generation and the verification are completely separate skills.

AI conflates vulnerability scanning with pen testing. Running npm audit is not a pen test. It checks for known CVEs in your dependencies. A pen test checks whether your application logic, authentication, authorization, and data handling are actually secure. Both matter. They're not the same thing.

How to Debug Security Findings with AI

When a pen test or security scan produces findings, AI becomes genuinely useful for understanding and fixing them. Here's how to use it effectively:

OWASP ZAP found this vulnerability in my Express.js app:

Alert: SQL Injection
Risk: High  
URL: POST http://localhost:3000/api/users/search
Parameter: query
Attack: ' UNION SELECT username, password FROM users --

Explain:
1. What this attack does in plain English
2. Why my code is vulnerable (I'm using pg with template literals)
3. The exact fix with parameterized queries
4. How to verify the fix worked

Step 1: Run the scan, don't just read about it. Install OWASP ZAP, point it at your local dev server (never scan production without permission), and run an automated scan. You'll get a list of findings sorted by severity. Don't panic — most apps have findings. Focus on High and Medium first.

Step 2: Feed each finding to your AI with context. Don't just say "fix SQL injection." Give it the exact alert, the URL, the parameter, and what your current code looks like. The more context AI has, the more specific and useful the fix will be.

Step 3: Verify the fix actually works. After implementing a fix, run the scan again. If the finding disappears, the fix worked. If it's still there, the fix was incomplete. This is the testing loop: find → fix → verify → repeat.

Step 4: Check for related vulnerabilities. If AI generated one SQL injection, there are probably more. Search your codebase for similar patterns — template literals with user input, string concatenation in queries, unsanitized data going to eval() or exec(). Ask your AI to audit the entire codebase for the same class of vulnerability:

I found SQL injection in my search endpoint because I used 
template literals in a pg query. Search my entire codebase for 
similar patterns:

1. Any db.query() call using template literals or string concatenation
2. Any raw SQL that includes ${} or + operator with user input
3. Any eval() or exec() calls with external data
4. Any response that sends raw database error messages to the client

List every file and line number. For each one, show the vulnerable 
line and the parameterized fix.

Your First Pen Test: A 30-Minute Checklist

You don't need to be a security expert to do a basic pen test. If you have 30 minutes, here's what to check:

1. Authentication bypass: Try logging in with ' OR 1=1 -- as username. Try empty passwords. Try the same password 100 times rapidly.
2. Authorization: Log in as User A. Try accessing User B's data by changing IDs in the URL. /api/users/123/profile → /api/users/456/profile.
3. Input validation: Put <script>alert('xss')</script> in every text field. Submit forms with missing required fields. Send 10MB strings.
4. API endpoints: Check if there are endpoints that don't require authentication. Try /api/admin, /api/debug, /api/test. Check if GraphQL introspection is on.
5. Secrets: View page source — any API keys, tokens, or passwords visible? Check /env, /.env, /config. Check JavaScript source maps for embedded secrets.
6. Error messages: Cause errors deliberately. Do the error messages reveal database structure, file paths, or stack traces? They shouldn't.
7. Dependencies: Run npm audit. Fix anything marked high or critical.

If your app passes all of these, you're ahead of 90% of AI-built apps. If it fails any of them, you've just found something that would have been found by someone less friendly eventually.

When to Hire a Professional

DIY pen testing catches the common stuff. But you should hire a professional pen tester when:

• Your app handles payment information (PCI compliance requires it)
• You store health data (HIPAA has security requirements)
• You have more than 1,000 users with personal data
• You're seeking enterprise clients who will ask for a SOC 2 report
• You've been breached and need to understand what happened
• Your app has complex business logic that automated tools can't understand

Professional pen tests typically cost $5,000–$50,000 depending on scope. For a vibe coder with a SaaS app making revenue, it's one of the smartest investments you can make. One data breach costs infinitely more — both in money and in trust.

What to Learn Next

• OWASP Top 10 for AI Coders — the industry standard list of web vulnerabilities, explained for vibe coders.
• What Is SQL Injection? — the most common vulnerability in AI-generated code, explained in depth.
• What Is XSS? — cross-site scripting attacks and how to prevent them in your AI-built frontend.
• What Is Input Validation? — the first line of defense against most attacks.
• What Is Dependency Scanning? — finding vulnerabilities in the packages AI pulls into your project.
• How to Review AI-Generated Code for Security — a systematic approach to auditing what AI creates.
• The LiteLLM Supply Chain Attack — a real-world March 2026 attack on a popular AI library, discovered using AI. Shows why pen testing and dependency scanning matter.

FAQ