Testing

Penetration Testing for Web Applications: A Practical Guide

HelpMeTest

HelpMeTest

— 6 min read
Penetration Testing for Web Applications: A Practical Guide

Penetration testing is the practice of deliberately attacking your own system to find vulnerabilities before attackers do. For web applications, this means systematically probing every input, every endpoint, and every authentication mechanism to find what breaks.

This guide covers the full pentest lifecycle for web apps — from reconnaissance through reporting — with practical steps you can apply to your own projects.

What Penetration Testing Is (and Isn't)

A penetration test is a controlled, authorized attack on a target system. The goal is to:

  1. Find real vulnerabilities — not just theoretical ones
  2. Demonstrate exploitability — not just identify weaknesses
  3. Assess impact — what could an attacker actually do?
  4. Produce actionable findings — not a list of CVEs to ignore

It's different from a vulnerability scan, which is automated and surface-level. A pentest involves human judgment, chaining vulnerabilities, and exploring application logic that scanners can't understand.

Who Should Do Penetration Testing?

  • QA engineers doing security testing as part of their role
  • Developers validating their own code before release
  • Security teams doing formal assessments
  • External consultants hired for independent validation

You don't need to be a security expert to find many common vulnerabilities. A solid understanding of HTTP, web application architecture, and the OWASP Top 10 gets you far.

The Penetration Testing Lifecycle

Phase 1: Reconnaissance

Before touching the target, gather everything publicly available about it.

Passive recon (no interaction with target):

  • WHOIS lookups for domain ownership
  • DNS enumeration for subdomains (dig, dnsx, amass)
  • Google dorking: site:example.com filetype:pdf or site:example.com inurl:admin
  • Certificate transparency logs (crt.sh) to find subdomains
  • GitHub/GitLab searches for exposed secrets or code
  • Shodan/Censys for exposed infrastructure

Active recon (interacts with target — ensure you have authorization):

  • Port scanning with nmap
  • HTTP header inspection
  • Technology fingerprinting with Wappalyzer or whatweb
  • Directory/file enumeration with feroxbuster or gobuster
# Enumerate subdomains
amass enum -d example.com

# Port scan
nmap -sV -sC -p- example.com

# Directory enumeration
feroxbuster -u https://example.com -w /usr/share/wordlists/dirb/common.txt

Phase 2: Mapping Attack Surface

Document everything you find:

  • All endpoints (authenticated and unauthenticated)
  • Input fields — forms, query parameters, headers, cookies
  • File upload functionality
  • Authentication mechanisms (login, password reset, 2FA)
  • API endpoints (REST, GraphQL, WebSocket)
  • Third-party integrations

Create a simple spreadsheet or use a tool like Burp Suite's site map to capture the full application structure. This becomes your testing checklist.

Phase 3: Vulnerability Assessment

Now you systematically probe each surface area.

Authentication testing:

  • Default credentials (admin/admin, test/test, etc.)
  • Brute force protection — can you try thousands of passwords?
  • Password reset flaws — predictable tokens, token reuse, no expiry
  • Account enumeration — does the app reveal which usernames exist?
  • Session management — session token entropy, fixation, hijacking

Input validation:

  • SQL injection in every parameter: ' OR '1'='1
  • XSS in all reflected inputs: <script>alert(1)</script>
  • XXE in XML endpoints
  • SSTI in template-rendering inputs: {{7*7}}
  • Command injection: ; whoami
  • Path traversal: ../../etc/passwd

Authorization:

  • Horizontal privilege escalation — can user A access user B's data?
  • Vertical privilege escalation — can a regular user access admin functions?
  • IDOR (Insecure Direct Object References) — change ?id=123 to ?id=124
  • Forced browsing — access URLs that aren't linked but exist

Business logic:

  • Negative values in price fields
  • Skipping steps in multi-step processes
  • Race conditions in concurrent requests
  • Mass assignment vulnerabilities

Phase 4: Exploitation

Once you identify a potential vulnerability, prove it's exploitable. This is what separates a pentest from a scan.

For SQL injection:

# Confirm injection
' AND 1=1--  (true condition — page loads normally)
' AND 1=2--  (false condition — page changes)

# Extract data with sqlmap
sqlmap -u "https://example.com/items?id=1" --dbs

For XSS, go beyond alert(1) — demonstrate actual impact by stealing a cookie or forging a request.

For IDOR, show that you can access another user's private data with just a changed ID.

Document everything. Screenshots, HTTP requests/responses, proof of exploitation. Your report is only as good as your evidence.

Phase 5: Post-Exploitation

After finding an initial vulnerability, explore what else it enables. Vulnerabilities chain together:

  • XSS + CSRF → account takeover
  • IDOR + sensitive data → PII exposure
  • SQL injection → database dump → cracked passwords → account access
  • Subdomain takeover → phishing or cookie theft

Understanding the blast radius helps stakeholders prioritize fixes correctly.

Phase 6: Reporting

The report is the deliverable. Every finding should include:

  1. Title — clear, descriptive name
  2. Severity — Critical/High/Medium/Low (use CVSS if formal)
  3. Description — what the vulnerability is
  4. Steps to reproduce — exact steps, anyone should be able to follow them
  5. Impact — what an attacker could do
  6. Evidence — screenshots, requests, responses
  7. Remediation — specific fix guidance, not just "sanitize inputs"

Group findings by severity, not by discovery order. Executives read the executive summary; engineers read the technical details.

Essential Tools for Web App Pentesting

Burp Suite

The standard for web application testing. Burp sits as a proxy between your browser and the target, letting you intercept, modify, and replay every request.

Key features:

  • Proxy — intercept and modify requests
  • Repeater — replay and tweak individual requests
  • Intruder — automated fuzzing and brute forcing
  • Scanner (Pro) — automated vulnerability scanning
  • Extensions — hundreds of community plugins

The free Community edition covers most manual testing needs. Pro adds the scanner and some advanced features.

OWASP ZAP

A free, open-source alternative to Burp Suite. Good for CI/CD integration because it has a full API and Docker image.

# Run ZAP baseline scan against a target
docker run -t owasp/zap2docker-stable zap-baseline.py -t https://example.com

sqlmap

Automated SQL injection detection and exploitation.

sqlmap -u "https://example.com/product?id=1" --level=3 --risk=2 --dbs

nikto

Fast web server scanner that checks for 6,700+ dangerous files/programs and outdated software.

nikto -h https://example.com

nuclei

Template-based vulnerability scanner with a massive community template library.

nuclei -u https://example.com -t nuclei-templates/

Common Vulnerabilities to Test First

Based on frequency and impact, prioritize these in any web app pentest:

  1. SQL Injection — direct database access, often critical
  2. Broken Authentication — account takeover
  3. IDOR — horizontal privilege escalation, very common
  4. XSS — session theft, phishing, defacement
  5. CSRF — forged user actions
  6. Security Misconfiguration — exposed admin panels, debug mode, default creds
  7. Sensitive Data Exposure — credentials in source, verbose errors, insecure storage
  8. Broken Access Control — vertical privilege escalation

These map directly to the OWASP Top 10, which is a required read for any security testing work.

Setting Up a Lab Environment

Practice pentesting on intentionally vulnerable applications before touching production:

  • DVWA (Damn Vulnerable Web Application) — classic PHP app with configurable vulnerability levels
  • Juice Shop (OWASP) — modern Node.js app, extensive vulnerability coverage
  • WebGoat (OWASP) — learning-focused with guided lessons
  • HackTheBox / TryHackMe — online platforms with ready-to-hack machines
# Run DVWA locally
docker run --rm -it -p 80:80 vulnerables/web-dvwa

# Run Juice Shop
docker run --rm -p 3000:3000 bkimminich/juice-shop

Integrating Security Testing Into CI/CD

Manual pentests happen periodically. Automated security checks should run on every build.

Add to your pipeline:

  • SAST (Static Analysis): Semgrep, CodeQL, Bandit (Python), Brakeman (Rails)
  • DAST (Dynamic Analysis): OWASP ZAP, Nuclei
  • Dependency scanning: npm audit, Snyk, Dependabot
  • Secret scanning: truffleHog, gitleaks
# GitHub Actions example
- name: Run OWASP ZAP Scan
  uses: zaproxy/action-baseline@v0.10.0
  with:
    target: 'https://staging.example.com'

See our guide on automated security testing in CI pipelines for a full setup walkthrough.

Never test systems you don't have explicit written authorization to test. This is not optional or situational — unauthorized penetration testing is illegal in most jurisdictions regardless of intent.

For production systems, get a signed scope-of-work or rules-of-engagement document that specifies:

  • What systems are in scope
  • What testing types are allowed (scanning, exploitation, social engineering)
  • Time windows for testing
  • Emergency contacts
  • Data handling rules

For your own applications, document your authorization internally. For third-party applications, check the bug bounty program or responsible disclosure policy.

What HelpMeTest Adds to Security Testing

Security testing isn't just about finding vulnerabilities — it's about knowing when new ones appear. HelpMeTest runs your tests continuously on a schedule, so when a deployment introduces a regression or a new endpoint appears without authentication, you find out immediately rather than at the next quarterly pentest.

For teams without a dedicated security engineer, scheduled functional tests that cover authentication, authorization, and input validation provide ongoing assurance between formal assessments.

Next Steps

  1. Set up Burp Suite and proxy your browser through it for one day of normal app usage — you'll be surprised what you find
  2. Install DVWA or Juice Shop and practice the basics
  3. Run nuclei against your staging environment
  4. Read the OWASP Testing Guide — it's the authoritative reference for web app pentesting
  5. Check out our OWASP Top 10 testing checklist for a structured approach to the most common vulnerability classes

Read more

Start now free