What actually gets exploited in penetration tests

Parth Upadhyay — Fri, 06 Feb 2026 06:04:12 +0000

I break into apps for a living. I'm a penetration tester at Fortica Cyberguard, which means companies pay me to find their security holes before the bad guys do.

After a few years of this, it's not some zero-day exploit that gets me in. It's usually the same handful of basic mistakes, over and over.

Access control
This one feels like cheating. You see a URL like /api/orders/12345? I change it to 12346 and suddenly I'm looking at someone else's order. That's it. Change a number and I can see data I shouldn't have access to.
I've downloaded entire customer databases by just looping through IDs.

The fix: Check if the logged-in user actually owns the data before you send it back. Include the user ID in your database query.

SQL injection
It's 2026 and I still find this everywhere. If you're building SQL queries by smashing strings together with user input, I will get into your database in about 5 minutes.

The fix: Use parameterized queries. Every database library has them. Or use an ORM - they handle it automatically.

Broken authentication
JWT secrets that are literally "secret123". Tokens that never expire. Session tokens in URLs. Secrets in public GitHub repos.
Once I get a valid token, I am that user. I've taken over admin accounts because someone left their JWT secret in a public repo.

The fix: Use strong random secrets (32+ characters, in environment variables). Make tokens expire. Hash passwords with bcrypt. Rate limit your login endpoint.

Exposed secrets
Hardcoded API keys. .env files committed to git. AWS credentials in public repos.
Once I have your keys, I don't need to find vulnerabilities. I just use your credentials to walk right in.

The fix: Add .env to .gitignore now. Use environment variables. Run trufflehog on your repos. If you already committed secrets, rotate them - they're in git history forever.

The mindset
These aren't sophisticated attacks. They're basic mistakes that are completely preventable.

The apps that give me the hardest time? The ones where developers thought about security while building. They questioned every input, verified every permission, assumed everything could be exploited.

That's the shift. Start thinking like someone trying to break your app, and you'll catch this stuff before it becomes a problem.

Questions? Drop them below.

5 Security Mistakes I See All The Time

Parth Upadhyay — Sat, 31 Jan 2026 14:39:19 +0000

I do security stuff at Fortica Cyberguard. Here are five things I keep finding in almost every codebase I look at. Not fancy exploits - just basic mistakes that keep happening.

1. Trusting client-side validation

Client-side validation is for UX, not security. Anyone can open DevTools and bypass it.
Found a file upload that checked extensions in JavaScript. Renamed a shell script to .jpg and uploaded it. Server accepted it, saved it in the web root. That's remote code execution in 30 seconds.

Fix:
Always validate on the server. Check file headers, not extensions. Validate everything - data types, ranges, formats.

javascript// This does nothing for security
if (!email.includes('@')) {
  showError('Invalid email');
}

// This actually matters (server-side)
const validator = require('validator');
if (!validator.isEmail(email)) {
  return res.status(400).json({ error: 'Invalid email' });
}

2. Secrets in environment variables

Environment variables aren't a security solution. They're just config.
Common issues:

.env files in git (found AWS admin keys this way multiple times)
Secrets in Docker build args (stays in image history - run docker history and see)
Environment dumps in startup logs
Secrets printed in error logs

Better:

Use actual secrets managers (AWS Secrets Manager, Vault, etc.)
For local dev, .env is fine but add to .gitignore
Rotate secrets regularly

dockerfile

# Bad - stays in image history
ARG DATABASE_PASSWORD=super_secret_123

# Better - injected at runtime
ENV DATABASE_PASSWORD=${DATABASE_PASSWORD}

3. Rolling your own auth

Just don't.
There's session management, password resets, rate limiting, token refresh, account enumeration prevention... it gets complex fast.

What happened: Built JWT auth for a side project. Forgot to validate the algorithm field. Someone sent a token with algorithm: none and it validated. Oops.

What to use:
Passport.js, NextAuth, Django auth, Devise - whatever's standard for your stack
Or just use Auth0, Supabase, Firebase
If you must build it, use bcrypt/argon2 and follow OWASP guidelines

Time saved not debugging auth edge cases > cost of these tools.

4. Ignoring dependency vulnerabilities

npm audit shows 47 vulnerabilities. "I'll fix that later."

Spoiler: Nobody fixes it later.
I run dependency scanners on repos during pentests. Companies have public package.json files showing vulnerable packages. Then it's just finding which one is used and exploiting it.

Real examples:
Equifax breach - unpatched Struts vulnerability
Log4Shell - affected thousands who were "too busy" to update
Found auth bypasses in old JWT library versions multiple times

Fix it:
Set up Dependabot or Renovate
Run security checks in CI/CD

Actually update things

bashnpm audit
pip-audit
# Then actually fix them
npm audit fix

5. Logging sensitive data

Found a production API logging full request bodies. Passwords, credit card numbers, everything. Logs were in Splunk, retained for 2 years, accessible to 30 people.
"Oh yeah, forgot to remove debug logs after launch." That was 3 years ago.
Watch out for:

Full request/response objects in logs
Exception handlers dumping everything
Debug logs in production
Authorization headers (Bearer tokens everywhere)
Long retention periods

Better:

javascript// Bad
logger.info('User login:', { user: userObject });

// Better
logger.info('User login:', { 
  userId: user.id, 
  timestamp: new Date()
});

Use proper log levels. Debug logs with sensitive data? Fine locally. Production? No.

Quick takeaway
These aren't sophisticated attacks. They're basic stuff that gets skipped when rushing to ship.
About 80% of critical issues I find in pentests are from this list. Not zero-days or nation-state hackers - just missing the basics.

Quick checklist:

Server-side validation on everything
Secrets in a proper manager
Use existing auth libraries
Update dependencies
Don't log sensitive data

That's it. Doing these consistently prevents most breaches I've seen.
What else do you see often? Always curious about common patterns.

DEV Community: Parth Upadhyay

What actually gets exploited in penetration tests

5 Security Mistakes I See All The Time