Web Application Penetration Testing
Manual, OWASP-aligned testing for the flaws scanners consistently miss
Automated scanning finds known patterns. It doesn't find the checkout flow that lets you apply a discount twice, or the endpoint that returns another tenant's records when you change one ID. We test manually against the OWASP Testing Guide and the OWASP Top 10, then chain what we find — because two medium-severity issues that combine into account takeover should be reported as account takeover.
What we cover.
- Defined URLs, domains, and application endpoints, with out-of-scope agreed in writing
- Black box, grey box (most common), or white box depending on what you need proven
- Passive and active reconnaissance across the application surface
- Full OWASP Top 10 coverage, plus business logic and access-control testing
- Vulnerability chaining, and post-exploitation where explicitly authorized
How the engagement runs.
Introduction
A web application penetration test is a specialised assessment that identifies and exploits vulnerabilities in a web application, its components such as APIs, and its underlying configuration. It simulates a targeted attack on the application layer to find flaws in code, logic, and implementation.
The goal is to find weaknesses an attacker could use to compromise the application, read or modify data, or affect other users — going well beyond scanning, to demonstrate the real business risk each flaw carries.
Web app test vs. network test
Network penetration test
Focuses on the underlying infrastructure — servers, firewalls, ports, services. It asks: can I compromise the server?
Web application test
Focuses on the application running on that server, usually on ports 80 and 443. It asks: can I compromise the application's code or logic?
Test phases
Planning and scoping
- Define objectives — state plainly what the test is trying to achieve.
- Gain administrative access
- Access another user's data
- Compromise the underlying server
- Define scope — list every target URL, domain, and API endpoint that is in scope, and state explicitly what must not be touched (partner domains, social engineering, denial-of-service).
- Define test type and credentials.
- Black box — no prior knowledge or credentials, simulating an external unauthenticated attacker
- Grey box (most common) — partial knowledge and credentials for one or more roles, so both unauthenticated flaws and authenticated privilege escalation get tested
- White box — full access to source, documentation, and diagrams, blending penetration testing with static analysis
- Establish rules of engagement.
- Authorization — explicit written permission before anything starts
- Testing window — specific dates and hours, often out of hours to avoid affecting production users
- Data handling — how any sensitive data encountered is handled, masked in the report, and securely purged afterwards
- Communication — a named contact for real-time escalation if something critical is found or a system stops responding
Reconnaissance and application mapping
- Passive reconnaissance — gathering information without touching the application: robots.txt and sitemap.xml, search-engine indexed pages and errors, and fingerprinting the technology stack.
- Active reconnaissance and spidering — probing the application to map its structure.
- Automated spidering through a proxy to crawl every reachable link, page, and directory
- Manual discovery — walking multi-step flows such as checkout or password reset by hand, because crawlers miss them
- Directory and file brute-forcing to surface unlinked paths such as /admin, backup archives, or an exposed .git directory
Vulnerability analysis
Systematic examination of the mapped application, following the OWASP Testing Guide and working the OWASP Top 10 (2021 edition) in full.
- Broken access control — the top risk. Users acting outside their intended permissions: a regular user reaching an admin page, or reading another user's records.
- Cryptographic failures — passwords stored in clear, weak algorithms, or data transmitted without TLS.
- Injection — untrusted data reaching an interpreter as part of a command or query. Most commonly SQL injection and cross-site scripting.
- Insecure design — architectural and design-level flaws that no amount of later patching fixes properly.
- Security misconfiguration — default passwords, unnecessary features left enabled, unpatched systems, or error messages that reveal too much.
- Vulnerable and outdated components — libraries and frameworks carrying known vulnerabilities.
- Identification and authentication failures — weak passwords accepted, missing multi-factor, or sessions that survive logout.
- Software and data integrity failures — trusting plugins, libraries, or updates from unverified sources, the supply-chain vector.
- Security logging and monitoring failures — critical events never logged or never watched, letting an intruder stay resident undetected.
- Server-side request forgery — the application fetching a remote resource from a user-supplied URL without validation, and being coerced into reaching internal systems.
Exploitation
Moving past identification into demonstrated business impact. Findings are chained to reach the maximum realistic effect, turning hypothetical risk into a tangible failure — always non-destructively, and never by exfiltrating real sensitive data.
- Chaining vulnerabilities — using the output of one flaw as the input to the next. A low-severity stored XSS in a comment field steals an administrator's session cookie when they view it; that cookie then grants full administrative control without ever needing a password.
- Gaining server access — moving from application compromise to operating-system control, typically through command injection or remote code execution that establishes a reverse shell back to us.
- Data exfiltration — demonstrating reach into sensitive data, for instance methodically walking a blind SQL injection through schemas and tables to prove the user database is reachable.
- Proving maximum impact — evidence must be undeniable, reproducible, and harmless.
- Privilege escalation — a timestamped screenshot of an admin panel that should have been unreachable
- Database compromise — retrieving a single non-sensitive row from the most protected table, proving the rest is reachable
- Server control — dropping a harmless marker file in the web root, or returning the hostname and kernel version over the shell
- Post-exploitation — run only where a server-level compromise succeeded, and only with explicit written authorization.
- Foothold and triage — stabilising access, enumerating OS version and the security context the web service runs as, and reviewing configuration files for clear-text credentials and API keys
- Internal reconnaissance — mapping interfaces, routes, and active connections, then discovering neighbouring hosts and services on the same subnets
- Privilege escalation — kernel and service exploits, weak service permissions, SUID abuse on Linux, unquoted service paths on Windows, credentials left in logs or memory
- Lateral movement — harvesting credentials and hashes, tunnelling or proxying through the compromised host, and targeting database servers, directory services, and source repositories
Reporting
- Executive summary — non-technical, framed around business risk, key findings, and overall posture.
- Technical report — written for the developers and IT team who will action it.
- Attack narrative — a step-by-step walkthrough of the most significant exploit chains.
- Vulnerability details — per finding: description, affected URLs and parameters, evidence including requests and responses, business impact, risk rating, and step-by-step remediation with code examples where useful.
Remediation and re-testing
- A debrief meeting to walk your team through the findings.
- Targeted re-testing once your developers have deployed fixes, to validate each issue is genuinely closed.
What you get at the end.
Who it's for
Product and engineering teams shipping web applications that handle money, personal data, or multi-tenant access.
Need a scope for this engagement?
Tell us what's in your environment and we'll come back with a scoped plan.
More in Offensive Infrastructure
Red Teaming
Full-scope adversary simulation against people, process, and technology
API Penetration Testing
Testing the headless surface — broken object authorization, mass assignment, oversharing
Mobile Application Testing
The binary, the device, and the backend it talks to