Scrolls
6 min read
On this page

Penetration Testing

Penetration testing is manual security testing performed by skilled testers who think like attackers. Unlike automated scans that check for known patterns, pentesters chain together findings, exploit business logic flaws, and discover vulnerabilities that no tool can find. A penetration test answers the question automated tools cannot: "Can a motivated attacker actually break into this system?"

What Penetration Testing Is

A penetration test simulates a real attack against your application, network, or organization. Testers use the same techniques, tools, and methodologies that actual attackers use — but with authorization and clear rules of engagement.

The scope is defined before testing begins. A typical scope statement specifies target systems, testing timeline, allowed techniques, and any systems that are off-limits (production databases with real customer data, for example).

# Example scope definition
Target:        app.example.com, api.example.com
Testing window: March 15-29, business hours only
In scope:       Web application, REST API, authentication flows
Out of scope:   Physical security, social engineering, DDoS
Contact:        security@example.com for emergencies

Testing Approaches

Black Box Testing

The tester has no prior knowledge of the system. No source code, no architecture diagrams, no credentials. They start the same way an external attacker would — with nothing but a URL or IP address.

Black box testing is realistic but time-limited. Testers spend significant time on reconnaissance that could be skipped with basic access. It best simulates an external attacker with no insider knowledge.

Grey Box Testing

The tester has partial knowledge — typically user-level credentials, API documentation, and a high-level architecture overview. This is the most common and practical approach for application testing.

Grey box testing balances realism with efficiency. Testers skip basic reconnaissance and spend more time on deep testing of application logic, authorization boundaries, and data handling.

White Box Testing

The tester has full access to source code, architecture documentation, database schemas, and administrative credentials. This is the most thorough approach and finds the most vulnerabilities.

White box testing is less realistic as an attack simulation but more effective as a security assessment. Testers can review code paths that would take weeks to discover externally, identify dormant vulnerabilities, and verify that security controls work as designed.

The Penetration Testing Process

Reconnaissance

Testers gather information about the target. For web applications, this includes mapping all endpoints, identifying technologies in use, and finding hidden functionality.

# Typical reconnaissance activities
- Enumerate subdomains and DNS records
- Map application endpoints and parameters
- Identify server technologies and frameworks
- Review JavaScript files for API endpoints
- Check for exposed configuration files
- Search for the application in public breach databases

Vulnerability Discovery

Testers probe each component for weaknesses. This goes beyond automated scanning — they test business logic, chained vulnerabilities, and edge cases.

# Example: testing authorization boundaries
1. Create two user accounts (user-a, user-b)
2. As user-a, create a resource (order #12345)
3. As user-b, attempt to access order #12345
4. Try modifying the order ID: /api/orders/12345
5. Try accessing admin endpoints: /api/admin/users
6. Test with expired, modified, or stolen tokens

Exploitation

When a vulnerability is found, testers attempt to exploit it to demonstrate real impact. The difference between a theoretical vulnerability and a proven exploit significantly affects how seriously the finding is treated.

A tester might chain a low-severity information disclosure with a medium-severity IDOR to achieve high-severity unauthorized data access. These chains are impossible for automated tools to discover.

Reporting

The deliverable is a detailed report documenting every finding with evidence, severity ratings, and remediation guidance. A good pentest report is actionable — developers can read it and fix issues without further consultation.

Bug Bounty Programs

Bug bounties crowd-source security testing by paying external researchers for valid vulnerability reports. They provide continuous testing from diverse perspectives, complementing periodic penetration tests.

How Bug Bounties Work

# Typical bug bounty reward structure
Critical (RCE, auth bypass, data breach):     $5,000 - $50,000
High (stored XSS, IDOR, privilege escalation): $1,000 - $10,000
Medium (CSRF, information disclosure):          $500 - $3,000
Low (missing headers, verbose errors):          $100 - $500

Platforms. HackerOne, Bugcrowd, and Intigriti connect organizations with security researchers. They handle triage, payment, and communication.

Private vs. public programs. Start with a private program (invitation-only researchers) to manage volume. Expand to public when your team can handle the report volume.

Duplicate handling. Multiple researchers often find the same vulnerability. Only the first valid report is rewarded. Clear policies prevent disputes.

Bug bounties are not a replacement for penetration testing. They complement each other — pentests are structured and thorough, while bug bounties provide continuous coverage from diverse viewpoints.

When to Pentest

Before major launches. Any new product, major feature release, or significant architectural change should be tested before going live.

Annually, at minimum. Even without major changes, annual testing catches drift — configuration changes, new dependencies, and evolving attack techniques.

After significant changes. Major refactors, new authentication systems, payment processing additions, or infrastructure migrations all warrant testing.

After a security incident. Post-incident testing validates that fixes are effective and checks for related vulnerabilities the attacker might have planted.

For compliance. PCI DSS requires annual penetration testing. SOC 2 auditors expect regular testing evidence. Many enterprise customers require pentest reports before signing contracts.

What to Expect from a Pentest Report

A professional pentest report includes several key sections.

Executive summary. A one-page overview for leadership: overall risk level, critical findings count, and key recommendations. No technical jargon.

Methodology. What was tested, how, and with what tools. This establishes the testing scope and helps reproduce findings.

Findings. Each vulnerability includes:

Finding: Insecure Direct Object Reference in Order API
Severity: High
CVSS Score: 7.5
Endpoint: GET /api/orders/{id}
Description: Any authenticated user can access any order by
  modifying the order ID parameter. No authorization check
  verifies the requesting user owns the order.
Evidence: [Screenshots, HTTP requests/responses]
Impact: Unauthorized access to customer order data including
  names, addresses, and payment information.
Remediation: Implement authorization check verifying the
  authenticated user owns the requested resource.

Remediation priority. Findings ranked by risk, with recommended fix timelines: critical (fix immediately), high (fix within 30 days), medium (fix within 90 days), low (fix in next development cycle).

Vulnerability Scan vs. Penetration Test

These are fundamentally different activities, though they are often confused.

Vulnerability scan. An automated tool checks for known vulnerabilities by matching signatures and configurations. It runs in minutes, costs little, and produces a list of potential issues. Many are false positives. Nessus, Qualys, and OpenVAS are common scanners.

Penetration test. A skilled human attempts to actually break into the system. They verify vulnerabilities, chain findings, test business logic, and prove real-world impact. It takes days or weeks, costs significantly more, and produces actionable findings with demonstrated impact.

A vulnerability scan tells you "this port is open and running an outdated version of Apache." A penetration test tells you "I used this outdated Apache version to gain a shell on the server, pivoted to the database, and extracted 10,000 customer records. Here is exactly how to fix it."

Run vulnerability scans frequently (weekly or monthly). Run penetration tests annually and before major releases. They are complementary, not interchangeable.

Common Pitfalls

  • Treating a vulnerability scan as a pentest. Automated scanning is useful but cannot replace human testing. Business logic flaws, authorization bypasses, and chained exploits require a human tester.
  • Pentesting only the web application. APIs, mobile backends, internal services, and infrastructure all need testing. Attackers target the weakest link.
  • Not fixing findings. A pentest report that sits unread is worse than useless — it cost money and provided no value. Assign findings to developers with deadlines.
  • Testing too late in the development cycle. Finding critical vulnerabilities a week before launch creates impossible choices. Test early and test often.
  • Choosing the cheapest pentest vendor. An inexperienced tester with automated tools provides little more than a vulnerability scan. Verify the team's credentials, methodology, and sample reports.
  • Not retesting after fixes. Fixes can be incomplete or introduce new issues. Schedule a retest to verify remediation.

Key Takeaways

  • Penetration testing is manual security testing by skilled testers who simulate real attacks.
  • Black box (no access), grey box (some access), and white box (full access) approaches serve different purposes.
  • Bug bounties provide continuous crowd-sourced testing that complements periodic pentests.
  • Pentest before major launches, annually, after significant changes, and after security incidents.
  • A good pentest report includes findings with evidence, severity ratings, and actionable remediation steps.
  • Vulnerability scans and penetration tests are complementary — scans are automated and frequent, pentests are manual and thorough.
  • The value of a pentest is only realized when findings are actually fixed and retested.