Need the #1 custom application developer in Brisbane?Click here →

Security

Penetration Testing

11 min readLast reviewed: March 2026

Penetration testing is authorized hacking—security professionals attempt to break your application to find vulnerabilities before malicious attackers do. This guide covers types of tests, tools, and how to use testing results to improve security.

What is Penetration Testing?

A penetration test is a simulated attack on your application. A security professional (or team) attempts to find vulnerabilities, exploit them, and report findings. Unlike a hacker, a penetration tester has authorization, works in a controlled manner, and provides a detailed report of findings and recommendations.

The goal is not to break things (though you should expect some disruption) but to identify security issues before they're exploited maliciously. A good penetration test provides a prioritized list of vulnerabilities, evidence of exploitability, and actionable remediation steps.

Types of Penetration Tests

Black Box Testing

The tester has no prior knowledge of the application. They attack it like an external attacker would—finding the application, gathering information, identifying attack surfaces, and attempting to exploit them. This mirrors real attacks but is harder (more time required to discover vulnerabilities) and may miss some issues.

White Box Testing

The tester has full access—source code, architecture diagrams, credentials. They can examine the code for vulnerabilities, test edge cases, and more efficiently find issues. This is more thorough but unrealistic (real attackers don't have this access) and may find issues that aren't exploitable in practice.

Grey Box Testing

The tester has partial knowledge—maybe they're an insider or have some credentials. This is the most realistic for many organizations and often the most cost-effective. It balances finding real exploitable issues with reasonable time/cost.

Automated Scanning vs Manual Testing

Penetration testing uses two complementary approaches:

Automated scanning: Tools like OWASP ZAP and Burp Suite automatically crawl your app, test endpoints, and look for common vulnerabilities (XSS, SQL injection, missing headers, etc.). Automated scanners are fast and find known vulnerabilities reliably. However, they miss complex logic flaws and can't understand business context.

Manual testing: A human tester explores the application, understands how it works, and attempts creative exploits. They find logic flaws (a user can approve their own expenses, privilege escalation chains, etc.) that automated tools miss. Manual testing is slower and requires expertise.

A comprehensive penetration test combines both. Automated scanning finds known issues quickly; manual testing finds logical flaws and creative attack chains.

Common Penetration Testing Tools

OWASP ZAP: Free, open-source web application scanner. Crawls your app, runs active and passive scans, and reports vulnerabilities. Good for continuous scanning in your CI/CD pipeline.

Burp Suite: Commercial proxy tool for manual testing. Allows intercepting requests, modifying them, and replaying them. Community edition is free but limited. Professional edition costs thousands per year.

Nikto: Scans for common misconfigurations, default credentials, and outdated software. Fast and useful for identifying obvious issues.

SQLMap: Automated tool for testing SQL injection vulnerabilities. If vulnerable, it can extract data automatically.

Continuous Scanning
Integrate automated scanners (OWASP ZAP, Snyk) into your CI/CD pipeline. Run them on every build to catch common vulnerabilities early. This doesn't replace penetration testing but catches obvious issues before they reach production.

When to Get a Penetration Test

You should conduct penetration tests at critical milestones:

Before launch: Your first penetration test should be before production. It's the most important one—fixing issues is cheaper before users are affected.

After major changes: If you add new features, change authentication, or refactor critical code, test again. Major changes introduce new vulnerabilities.

Compliance requirements: HIPAA, PCI-DSS, SOC 2, and other standards often require periodic penetration testing. Check your compliance requirements.

Continuously: Large organizations with security teams run continuous testing—automated scanners run always, and manual testing happens regularly. This is overkill for small teams but is the gold standard for mature security programs.

Understanding a Penetration Test Report

A penetration test report details findings, typically organized by severity. Each finding includes:

Description: What the vulnerability is and how it works.

Evidence: How the tester exploited it—a screenshot or step-by-step reproduction.

Impact: What an attacker could do with this vulnerability.

Remediation: How to fix it.

CVSS Score: A severity rating from 0-10. 9-10 is critical; 7-8 is high; 4-6 is medium; 0-3 is low.

CVSS Scoring

The Common Vulnerability Scoring System (CVSS) provides a standardized way to rate vulnerability severity. It considers:

Attack Vector: Can the attacker reach the vulnerability locally or over a network?

Privileges Required: Does the attacker need authentication or admin access?

User Interaction: Does the user need to do something to trigger the vulnerability?

Impact: What does successful exploitation affect—confidentiality, integrity, availability?

A vulnerability that can be exploited remotely without authentication and affects confidentiality scores high. A vulnerability that requires local access and admin privileges scores low.

Prioritizing Findings

Penetration test reports can overwhelm—a large application might have 50+ findings. Prioritize based on:

Severity: Critical and high findings first. Fix these immediately.

Exploitability: Can the vulnerability be reliably exploited or does it require specific conditions?

Impact: What's the business impact if exploited? Data theft or a minor information leak?

Effort: How long will the fix take? Quick wins (fixing a header, applying a patch) should be done immediately.

Don't Ignore Low Severity Findings
Low severity findings can chain together to create high-impact attacks. A minor information leak combined with weak authentication might enable account takeover. Review all findings and don't dismiss them based on CVSS score alone.

Bug Bounty Programs

Rather than hiring testers once, establish a bug bounty program. Offer rewards for security researchers who find and responsibly disclose vulnerabilities. Platforms like HackerOne and Bugcrowd connect you with researchers worldwide.

Bug bounties provide continuous testing and incentivize researchers to find real issues. Rewards vary (100 dollars to thousands) depending on severity and your budget. This is cost-effective compared to periodic penetration testing and provides broader perspectives as many independent testers look at your app.

Internal Security Reviews

You don't need external testers for everything. Your own engineers can perform security reviews:

Code review: Review changes for security issues. Train your team on OWASP Top 10 and secure coding practices.

Threat modeling: Identify potential attack vectors early. What could go wrong in this feature?

Automated scanning: Run scanners in CI/CD. Catch vulnerabilities before they reach production.

Internal reviews don't replace external testing (you bring blind spots) but are more cost-effective for continuous security work.

Choosing a Penetration Testing Company

If hiring external testers, look for:

Certifications: OSCP (Offensive Security Certified Professional) is highly respected. CEH is common but less rigorous.

Experience: Have they tested applications similar to yours? Do they understand your tech stack?

References: Ask for references from other companies they've tested. Call them.

Process: Do they provide a detailed scope, methodology, and reporting format? Professional testers should have a clear process.

Expect to pay 2,000-15,000 dollars per test depending on scope and complexity. A good test is worth the investment.

Common Findings in Web Applications

Most penetration tests find similar issues:

✓ Missing or misconfigured security headers

✓ Broken access control (users accessing other users' data)

✓ Weak authentication (no MFA, weak password requirements)

✓ Sensitive data exposure (credentials in logs, unencrypted PII)

✓ Input validation flaws (injection, XSS)

✓ Insecure dependencies (outdated libraries with known vulnerabilities)

If you implement the best practices in this guide—proper authentication, authorization, input validation, encryption, security headers, and dependency management—you'll already prevent most findings. Penetration testing finds edge cases and combinations of issues that create vulnerabilities.