← jacob.masse

Pentest Your Own Product Before Someone Else Does

Over my time at Lorikeet Security, I found over 20 vulnerabilities across client applications. Most of them were preventable. Not edge cases, not zero-days, just standard issues that the OWASP Top 10 has warned about for over a decade. Broken access controls, injection flaws, misconfigured authentication. The kind of bugs that make headlines when they get exploited and make engineers say "we should have caught that" in the postmortem.

You do not need to hire a pentest firm to find these. You need to start testing your own product with an attacker's mindset. Here is how.

Why Internal Testing Matters

External penetration testers are valuable. I have been one. But they operate with constraints: limited time, limited context, limited access. A typical engagement runs one to two weeks. Your development team ships code every day. The math does not work if you rely on annual pentests as your primary security validation.

Internal testing fills the gap. Your developers know the codebase. They know which endpoints were built in a rush, which features skipped code review, which integrations were wired up by a contractor who left six months ago. That institutional knowledge is a massive advantage when looking for vulnerabilities.

The goal is not to replace external testers. It is to catch the obvious issues before they arrive, so the external team can focus on the hard stuff.

Start with the OWASP Top 10

The OWASP Top 10 is not a comprehensive security framework. It is a prioritized list of the most common web application vulnerabilities. That makes it the perfect starting checklist for internal testing.

Here is where I would focus first:

A01: Broken Access Control

This is the number one vulnerability category for a reason. Test every API endpoint with different user roles. Can a regular user access admin routes by changing the URL? Can user A read user B's data by modifying an ID parameter? Can you bypass authorization by removing a JWT token and falling through to a default-allow path?

The test is simple: log in as a low-privilege user and try to perform every action that should be restricted. Use Burp Suite or even just curl to replay requests with modified parameters. I find access control bugs in nearly every application I test. They are that common.

A03: Injection

SQL injection gets the most attention, but injection flaws exist everywhere: NoSQL queries, LDAP lookups, OS commands, template engines. Any place where user input gets concatenated into a query or command is a potential injection point.

Test by submitting unexpected input. Single quotes, semicolons, template syntax like {{7*7}}, OS command separators. If you see a 500 error or unexpected output, dig deeper. Modern ORMs prevent most SQL injection, but raw queries still appear in search features, reporting endpoints, and data export functions.

A07: Identification and Authentication Failures

Test your login flow thoroughly. Does the application enforce rate limiting on login attempts? Can you enumerate valid usernames through different error messages? Are password reset tokens single-use and time-limited? Does session fixation work?

One test I always run: log in, capture the session token, log out, and replay a request with the old token. If it works, your session invalidation is broken. This is a surprisingly common issue with JWT-based authentication where tokens are validated against a signing key but never checked against a revocation list.

Beyond OWASP: Business Logic Flaws

Automated scanners and standard checklists miss business logic vulnerabilities entirely. These are the bugs that require understanding what the application is supposed to do.

Examples I have found in real engagements:

• An e-commerce checkout that applied discount codes after calculating tax, allowing negative totals
• A file sharing app that checked permissions on download but not on generating preview thumbnails
• An approval workflow that let users approve their own requests by modifying the approver field in the API call
• A subscription service that granted premium access during the trial-to-paid transition window regardless of payment status

These bugs require human creativity to find. No scanner will flag them. Your developers, the people who built these workflows, are actually well positioned to think about how they could be abused. The trick is getting them to switch from "how should this work" to "how could this be misused."

The Testing Process

Here is a practical workflow for running an internal pentest:

1. Scope it. Pick one feature area per session. Trying to test everything at once leads to shallow coverage. Focus on high-risk areas first: authentication, payment processing, data access, admin functionality.
2. Set up a proxy. Install Burp Suite Community Edition or OWASP ZAP. Route your browser traffic through the proxy. This lets you inspect, modify, and replay every request the application makes.
3. Map the attack surface. Click through the feature as a normal user while the proxy captures traffic. Review every endpoint, parameter, and header. Note which ones accept user input.
4. Test systematically. For each input point, try the standard attacks: injection payloads, access control bypasses, parameter manipulation. Document what you test and what you find.
5. Write it up. A finding without documentation is worthless. Record the vulnerability, reproduction steps, impact assessment, and recommended fix. Use severity ratings (Critical, High, Medium, Low) consistently.

When to Bring in External Testers

Internal testing has blind spots. Your team built the application, which means they share the same assumptions that created the vulnerabilities in the first place. External testers bring fresh eyes and different attack methodologies.

Bring in external testers when:

• You are preparing for a compliance audit (SOC 2, ISO 27001, PCI DSS)
• You are launching a new product or major feature
• You have not had an external test in over 12 months
• You are handling sensitive data categories (healthcare, financial, PII)
• A customer or partner requires a third-party assessment

When selecting a firm, look for testers with experience in your technology stack and industry. Ask for sample reports. A good pentest report includes clear reproduction steps, business impact analysis, and prioritized remediation guidance. A bad report is a scanner dump with no context.

Building a Security Testing Culture

The biggest impact is not any single test. It is making security testing a normal part of development. Here is what works:

Run a monthly "break it" session where developers spend two hours trying to find vulnerabilities in each other's features. Make it collaborative, not competitive. Share findings openly without blame. Track metrics: vulnerabilities found internally versus externally. Your goal is to shift that ratio toward internal discovery over time.

Add security test cases to your definition of done. Every user story that involves authentication, authorization, or data handling should include at least one security-focused test case. Not a penetration test, just a deliberate check that the security controls work as designed.

The reality is straightforward: someone will test your product's security eventually. It is better if that someone is you.