WEB APPLICATION PENETRATION TESTING

Your web application is the part of your business an attacker can reach without ever touching your network. Every login form, API endpoint, session token, file upload, and half-forgotten admin path is exposed to anyone with a browser, all day, every day. A vulnerability scanner covers some of that surface, but it cannot chain a weak access control into an account takeover, and it has no idea what your workflow is supposed to allow — so it will happily pass an application that lets one customer approve another customer's transactions. We test web applications manually: the technical flaws a scanner only hints at, and the business logic abuse it can never see. Our team has written about the limits of web application VA scanners — this page covers what a full manual test adds on top. What you receive is a set of findings your developers can reproduce, prioritise, and fix.

What we test

Every finding is mapped to the OWASP Top 10 (2025), so what we report lines up with the framework your developers and auditors already know — no translation layer between the report and your remediation backlog. The current top-ten risk categories are:

• A01:2025 Broken Access Control — users acting outside their permissions (now includes SSRF).
• A02:2025 Security Misconfiguration — insecure defaults, exposed settings, missing hardening.
• A03:2025 Software Supply Chain Failures — risk in dependencies, build systems, and distribution.
• A04:2025 Cryptographic Failures — weak or missing cryptography exposing sensitive data.
• A05:2025 Injection — untrusted input executed by the app (SQL injection, XSS, and more).
• A06:2025 Insecure Design — security controls missing or ineffective by design.
• A07:2025 Authentication Failures — weak identity, credential, or session handling.
• A08:2025 Software or Data Integrity Failures — unverified updates/data, insecure deserialization.
• A09:2025 Security Logging & Alerting Failures — gaps that stop you detecting or responding to an attack.
• A10:2025 Mishandling of Exceptional Conditions — improper error handling, failing open (new in 2025).

In practice our coverage goes deeper than the framework's ten headings — it includes, but is not limited to, a defined set of test categories covering the application from the login page down to the server it runs on:

• Authentication — credential handling, brute-force resistance, password policy, and account-recovery flows.
• Session & cookie management — token generation and entropy, expiry, fixation, and cookie attributes.
• Access control & authorization — whether each role can reach only what it should, and nothing more.
• Data validation — how the application handles unexpected, malformed, or hostile input.
• Parameter tampering — manipulation of prices, quantities, identifiers, and hidden fields.
• Injection (various) — SQL, command, LDAP, template, and other injection classes across every input.
• Cross-site scripting (XSS) — reflected, stored, and DOM-based script injection.
• Cross-site request forgery (CSRF) — forcing an authenticated user's browser into unintended actions.
• Insecure direct object reference (IDOR) — reaching other users' records by changing an identifier.
• Use of cryptography — weak algorithms, poor key handling, and home-grown crypto.
• Clear-text transmission & sensitive information exposure — data sent, stored, or leaked without protection.
• Error & exception handling — stack traces and error messages that reveal internals to an attacker.
• Administration interface & access control — exposed or under-protected administrative functions.
• Application business logic — abuse of the workflow itself: skipping steps, replaying transactions, bending the rules the application exists to enforce.
• Web/application server security configuration — the platform underneath the code: headers, services, defaults, and patch state.

How we test

Two kinds of testing run in every engagement, and the distinction matters. Technical testing targets implementation flaws — injection, XSS, broken session handling — vulnerabilities that exist regardless of what the application is for. Business logic testing targets the application's own rules: what happens when someone follows the workflow in the wrong order, approves their own request, sets a negative quantity, or uses one role's access to reach another role's data. Logic flaws are invisible to scanners because nothing is technically broken — the application does exactly what it was built to do, just for the wrong person. In practice, this is where many of the highest-impact findings live, and it is a deliberate, standing part of our methodology rather than an optional extra.

Around that, the engagement follows the same phases as every penetration test we run:

1. Preparation & scoping — We agree the applications, environments, and testing scenario. Black-box simulates an external attacker with no prior knowledge of the system; gray-box gives us credentials for every user role, so we can test the business process itself — including vertical privilege escalation (a normal user reaching admin functions) and horizontal privilege escalation (one user reaching another user's data). We also agree the vantage point: external testing from the Internet, or internal testing from your intranet for applications that never face the public. You get a proposal with a fixed timeline and no open-ended billing.
2. Technical testing — Manual testing across the category checklist above, against the agreed scope. Automated tooling assists with coverage, but every reported issue is validated by hand — no raw scanner output ever reaches the report.
3. Business logic testing — With role credentials in hand, we walk the application's workflows the way a motivated fraudster or malicious insider would: out-of-order steps, tampered parameters, cross-role access, and abuse of the features that make the application useful.
4. Reporting & retest — Findings are rated by Risk Level (Critical, High, Medium, Low) with a POC and remediation guidance for each, plus an executive summary for management. After your team fixes the issues, we retest and update the report to reflect what has been closed.

What you get

Every report contains, at minimum:

• Executive summary — the business-level risk picture, suitable for management and auditors.
• Findings by Risk Level — each vulnerability rated Critical, High, Medium, or Low and mapped to the OWASP Top 10 (2025), so remediation can be prioritised objectively.
• POC for every finding — exact requests, payloads, and screenshots; your engineers should never need to guess how we got in.
• Remediation guidance — practical fixes for your stack, not a copy-paste of scanner boilerplate.
• Retest verification — findings are re-checked after your fixes and the report is updated to reflect closed items.

Consistent with our track record across the practice, we have delivered zero blank pentest reports — every engagement so far has surfaced real, validated findings.

Team credentials

Testing is performed by our in-house team holding industry certifications including OSCP, OSCE, CREST CRT, CREST CPSA, and GIAC GREM — credentials earned through rigorous, hands-on examination, not multiple-choice exams. See the full list of certifications the team holds.

Standards

Our methodology follows NIST SP800-115 (Technical Guide to Information Security Testing and Assessment), aligned with the Penetration Testing Execution Standard (PTES) and OSSTMM, with findings mapped to the OWASP Top 10 (2025). If your application sits in a payment-card environment, the web pentest feeds directly into the wider PCI DSS scope — scoped and reported the way QSAs expect. Tell us during scoping what your audit needs; aligning the report costs nothing at that stage.