Practical Guide to Web Penetration Testing

Web penetration testing simulates real-world attacks against web applications to identify exploitable vulnerabilities. It combines automated scanning with manual testing, tool-assisted exploration with creative thinking, and technical analysis with an understanding of business risk.

Authoritative methodologies include the OWASP Web Security Testing Guide (WSTG), PTES (Penetration Testing Execution Standard), and NIST SP 800-115. The OWASP Top 10 and ASVS (Application Security Verification Standard) provide vulnerability coverage and verification rigor. The WSTG in particular structures the work into recon, configuration, identity, authentication, session management, authorization, input validation, error handling, cryptography, business logic, client-side testing, and API testing.

Two patterns dominate test outcomes. First, authorization bugs everywhere: missing checks, wrong subjects, IDOR, mass assignment. Second, business logic flaws that no scanner can find: bypassing workflow steps, abusing race conditions, gaming pricing engines, exploiting validation gaps in multi-step flows.

A pentest is bounded by scope and rules of engagement. Document both before starting. Authorization in writing is non-negotiable.

Define scope precisely. Which domains, subdomains, IP ranges, applications, and APIs are in scope? What types of testing are permitted: blackbox, greybox, whitebox? What times of day? What attack techniques are excluded (denial of service, social engineering, physical)? Get written authorization from a party with authority to grant it.

Set objectives. Compliance assessment, breach simulation, specific feature review, and pre-release validation drive different methodologies. Knowing the objective shapes effort allocation.

Establish communication. Who is the primary point of contact, both during business hours and for emergencies? What is the escalation path if you find a critical issue or accidentally cause an incident?

Set up your toolkit. Burp Suite Professional and OWASP ZAP are the workhorses for HTTP traffic manipulation. Browser developer tools, ffuf or feroxbuster for fuzzing, nuclei for templated checks, sqlmap for SQL injection, jwt_tool for token analysis, and a quick scripting environment (Python with requests, or PowerShell) round out the kit.

Document everything as you go. Screenshots, raw requests and responses, command output, and notes about thinking. Reports written from comprehensive notes are dramatically better than reports written from memory.

Map the attack surface. Even with a defined scope, the application may include subdomains, APIs, mobile backends, admin panels, and forgotten endpoints. Tools like subfinder, amass, httpx, and waybackurls surface assets. nuclei templates probe for common exposures.

Crawl the application thoroughly. Burp's spider, ZAP's spider, and headless browser crawlers (Playwright with custom scripts) discover URLs, parameters, and forms. Authenticate as different user types and crawl each separately; access differences become test cases.

Identify the technology stack. Wappalyzer, Burp passive scans, response headers, error messages, and source code comments reveal frameworks, languages, and library versions. The stack determines which vulnerability classes are likely.

Inventory parameters. URL parameters, body parameters, headers, cookies, and JSON fields are all input vectors. Tools like Arjun and ParamSpider find hidden parameters worth probing.

Find the auth surface. Login, registration, password reset, MFA enrollment, OAuth, SAML, session management, and account recovery flows each warrant focused testing.

Look at JavaScript. Modern apps push significant logic to the client. linkfinder, jsmon, and manual review of webpack bundles surface API endpoints, hidden features, and sometimes credentials.

Broken Access Control is the highest impact category. Test horizontal escalation: can user A access user B's data by changing identifiers? Test vertical escalation: can a regular user access admin functions by guessing URLs or modifying requests? Test object-level (BOLA) and function-level (BFLA) authorization for every endpoint with multiple user roles.

Cryptographic Failures. Look for weak TLS configurations (testssl.sh, SSL Labs scanner), data sent in clear, weak hashing (MD5, SHA-1) for passwords, hardcoded keys in client-side code, and JWT tokens with weak algorithms.

Injection. SQL injection: try classic payloads in inputs that reach databases. Use sqlmap for systematic testing. Command injection: test inputs flowing into shell calls. XSS: reflected (URL parameters), stored (comments, profiles), DOM-based (client-side sinks). NoSQL injection: try MongoDB/Redis operators. LDAP, XPath, and SSTI when applicable.

Insecure Design. Look for missing rate limits on sensitive actions, lack of out-of-band verification on high-value flows, and business logic that allows bypassing intended workflows. These need domain understanding, not just tools.

Security Misconfiguration. Default credentials on admin panels, exposed .git directories, accessible /actuator endpoints (Spring), debug mode in production, verbose error messages, missing security headers, default sample applications.

Vulnerable Components. Identify framework and library versions; check against known CVEs. Public scanners may not catch everything; manual review of dependencies pays off for high-impact applications.

Authentication Failures. Username enumeration through differential responses, missing rate limits on login, weak password policies, session fixation, predictable session tokens, MFA bypass, password reset flaws.

Software and Data Integrity Failures. Unsigned updates, deserialization of untrusted data (Java, .NET, PHP, Python pickle), CI/CD exposure.

Logging and Monitoring Failures. Probe for lack of detection: fail many logins, attempt admin actions, see whether anyone notices. Note these for the report; they are critical to detection capability.

Server-Side Request Forgery. Look for any input that becomes a URL fetched by the server. Test for internal network access, cloud metadata endpoints (169.254.169.254 on AWS, equivalent on Azure and GCP), and bypasses via DNS, redirects, and URL parsing differentials.

Business logic flaws are where scanners fail and pentesters shine. Understand the application as a user before testing as an attacker. Walk through each workflow as intended, then ask: what if I skip a step? What if I do steps in a different order? What if I do the same step many times? What if I do steps as a different user?

Common business logic flaws include: bypassing checkout steps to get discounts, ordering negative quantities, applying coupon codes multiple times, exploiting race conditions to double-spend, abusing referral programs, bypassing limit checks, accessing features outside your subscription tier, and exploiting trial/free-tier abuse.

Race conditions deserve special attention. Tools like Turbo Intruder and the Burp Repeater "Group" feature send many requests simultaneously. Resource creation that should be limited, state transitions that should be atomic, and balance-changing operations are all candidates.

Mass assignment occurs when an application binds request fields directly to backend models without filtering. Try adding fields you should not control: isAdmin, role, accountStatus, subscriptionTier. Many APIs accept extra fields silently.

File upload functionality is fertile ground. Test for unrestricted file types (upload an HTML or SVG file with JavaScript and access it directly), path traversal in filenames, oversized files, and processing flaws (XXE in XML parsers, SSRF in image processors that fetch remote resources).

Burp Suite Professional or OWASP ZAP as the central proxy. Configure for thorough passive scanning; use active scanning carefully with rate limits and scope restrictions.

Use authenticated scanning. Configure Burp/ZAP with valid session cookies or tokens for each user role tested. Many vulnerabilities only appear in authenticated contexts.

Automate the repetitive. Burp's Intruder, ffuf, and feroxbuster handle fuzzing. nuclei runs hundreds of templated checks across hosts. Save manual time for the interesting things.

Use specialized tools when appropriate. sqlmap for confirmed SQL injection, jwt_tool for JWT manipulation, hashcat for cracking captured hashes, Hydra for credential testing in authorized scopes.

Maintain a testing environment. A VM with your toolkit configured, browser profiles for each test user, and a notes structure ready accelerates every engagement.

Test in waves. First pass with automation to surface low-hanging fruit. Deep manual testing on authentication, authorization, and business logic. Final pass to verify exploitability and gather evidence.

A pentest report is the deliverable. A report no one reads or acts on wasted everyone's time.

Lead with an executive summary. One page that any executive can read: top risks, business impact, recommendations. Avoid technical jargon. Tie findings to business outcomes.

For each finding, include: title, severity (with rationale, ideally CVSS), affected component, description, evidence (screenshots, request/response, reproduction steps), business impact, and remediation guidance. The reader should be able to confirm and fix without going back to you.

Be specific in remediation. "Implement proper input validation" is not actionable. "In file OrderController.cs line 47, change the SQL string concatenation to a parameterized query using SqlCommand.Parameters.AddWithValue" is.

Rank realistically. Inflated severities lose trust. Aligning to a published rubric (CVSS, OWASP Risk Rating) provides defensibility.

Include positive findings. Note where the application was strong. Defenders need encouragement; engineers respond well to recognition of good work.

Provide a retest. Offer to verify fixes within a defined window. Closed findings are the real measure of pentest value.

Authorization bugs make up an enormous share of disclosed pentest findings across industries. The pattern is consistent: authenticated endpoints that fail to enforce object ownership. The fix is usually a single check; the absence has caused breaches at fintech, healthcare, and SaaS companies.

SSRF has emerged as a major class of pentest finding, often via image processors, webhook handlers, and PDF generators. The Capital One breach in 2019 was an SSRF leveraging EC2 metadata; pentesters routinely find similar patterns.

In 2024, multiple disclosed pentest reports highlighted JWT algorithm confusion: backends accepting tokens signed with HMAC and a key derived from the publicly available RSA public key. Token validation libraries that allow algorithm "none" or accept any signature still ship in production.

Mass assignment continues to appear in MVC frameworks where developers bind request bodies directly to models. Tools that detect mass assignment patterns, combined with code review and pentest, are the operational defense.