Web Application Penetration Testing: OWASP Top 10, Burp Suite and Manual Testing Methodology

Quick answer: Web application penetration testing means proving exploitable vulnerabilities by testing an application's authentication, authorization, input handling and business logic layers like a real attacker. The framework is the OWASP Top 10 2021: A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection (including SQL injection and XSS), A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable and Outdated Components, A07 Identification and Authentication Failures, A08 Software and Data Integrity Failures, A09 Security Logging and Monitoring Failures, A10 Server-Side Request Forgery (SSRF). The methodology is the OWASP Web Security Testing Guide (WSTG), the primary tool is Burp Suite. An automated scanner sweeps the surface; only manual testing finds business-logic and authorization flaws. So the two are needed together. In Verizon's annual breach reports, basic web application attacks rank among the top breach patterns.

Web applications are the broadest and most frequently attacked internet-facing surface of organizations. A company's ten years of work, the API behind a mobile app, an e-commerce site's payment flow or an enterprise portal's session management all sit on this surface. In Verizon's annual breach reports (DBIR), basic web application attacks rank among the top breach patterns, and most of these attacks use stolen credentials. Web application penetration testing does not treat this surface as a mere scanner report; it builds and proves, in an authorized way, the chains a real attacker would use, shows them with an executable proof and provides a remediation roadmap.

This article complements our pieces on API security penetration testing and web site security service; here the focus is manual testing that deeply probes the application's own logic. For the internal network side see Active Directory internal network penetration testing, and for service types see red team vs pentest vs purple team.

What the OWASP Top 10 is, and why it is the framework

The OWASP Top 10 is the OWASP Foundation's consensus list of the ten most critical security risks in web applications. The current stable version is 2021; in 2021 three new categories (A04 Insecure Design, A08, A10 SSRF) were added and others reorganized. OWASP announced a newer edition in 2025; but for a stable citation we anchor our tests on the 2021 list and refer to 2025 as the newer edition. The Top 10 is a risk map, not a test checklist. Saying an application "was tested against the OWASP Top 10" is not enough on its own; the actual methodology is the OWASP Web Security Testing Guide (WSTG), the open-source guide the world effectively uses to test the security of applications and services.

The value of the Top 10 is that it builds a shared language with the engineering team. When a finding is labeled "A01 Broken Access Control," the developer instantly understands the class of risk, why it matters and where to look. This shared language is what turns a report into remediation rather than shelfware.

Methodology: the six phases of the test

A solid web application penetration test is not haphazard trial and error but a structured process. Under WSTG's topics we run the test in six phases.

  1. Information gathering and mapping. All pages, parameters, API endpoints, hidden directories and technologies of the application are enumerated. Without knowing the attack surface the test is incomplete.
  2. Authentication and session management testing. The login flow, password reset, generation and invalidation of session tokens, multi-factor authentication and "remember me" mechanisms are tested.
  3. Authorization testing. Whether a user can reach data or functions they are not authorized for; vertical (low to high privilege) and horizontal (another user's data at the same level) privilege escalation are attempted.
  4. Input validation testing. Injection (SQL, command, template), XSS and other input-based vulnerabilities are sought.
  5. Business logic testing. Abuse of the application's business rules (for example reusing a discount code, placing an order with a negative amount) is tested. This is the most valuable stage, invisible to automated tools.
  6. Reporting and retest. Findings are presented with an executable proof, a risk rating and a clear remediation step; closure is confirmed with a retest after remediation.

The most exploited vulnerabilities

A01 Broken Access Control and IDOR

In the OWASP Top 10 2021 the number-one risk is broken access control: a user reaching data or functions they are not authorized for. Its most common form is IDOR (Insecure Direct Object Reference): accessing someone else's data by changing the object identifier in a request (for example /account/1005 instead of /account/1004). A typical attack flow is: the tester views an invoice with their own account, increments the invoice number in the request and sees another customer's invoice. These are the flaws automated scanners most often miss, because you must know the application's business context and who should access what; only manual testing finds them. Defense is to check "can this user access this object" on the server side for every request.

A03 Injection: SQL Injection and XSS

In 2021 the Injection category also absorbed XSS, previously its own category. SQL injection is when user input is concatenated directly into a database query, letting the attacker manipulate the query to read or modify data; in the extreme it can lead to dumping the whole database or bypassing authentication. Cross-Site Scripting (XSS) is when the attacker injects executable script into a web page that runs in other users' browsers; it can lead to stealing session cookies, showing fake forms and account takeover. Both are documented interactively at the PortSwigger Web Security Academy. SQL injection is prevented with parameterized queries (prepared statements), XSS with context-aware output encoding and a content security policy (CSP).

A10 Server-Side Request Forgery (SSRF)

SSRF is when the attacker tricks the application into making a request on the server's behalf. It is especially dangerous in cloud environments: the attacker can make the application request the cloud provider's internal metadata endpoint to leak temporary credentials and spread from there to the whole cloud account. Added to the Top 10 in 2021, this category became critical as cloud architectures spread. Defense is to restrict outbound requests with an allowlist and block access to internal addresses; for the cloud side see our cloud security assessment.

A07 Identification and Authentication Failures

Weak password policies, flawed session management, breakable password-reset flows and missing multi-factor authentication fall here. In the pentest the authentication flow is tested in detail: are session tokens predictable, are they invalidated after logout, can the password-reset token be reused, is there account lockout, is there protection against brute force and credential stuffing. These are critical because they lead directly to account takeover.

A05 Security Misconfiguration and A06 Vulnerable Components

Misconfiguration (open admin panels, default credentials, verbose error messages, unnecessary open services) and outdated, known-vulnerable components are the areas that produce the most findings in most tests. A single outdated version of a library can lead to remote code execution through a known CVE. For software supply chain and component security see our source code security review (SAST, DAST, SCA).

The basis of the methodology: WSTG and ASVS

The OWASP Web Security Testing Guide (WSTG) is the de facto methodology penetration testers use worldwide, structured into topics such as information gathering, authentication testing, session management testing, authorization testing, input validation testing and business logic testing; its current stable version is 4.2. OWASP ASVS (Application Security Verification Standard) provides a basis for testing technical security controls and defining secure-development requirements; it is also used as a requirements list in procurement contracts. At DSET we run tests under WSTG topics and map findings to ASVS levels; so the customer gets not only "this vulnerability exists" but also "at which maturity level there is a gap."

Why automated and manual testing are both needed

Automated scanners (DAST tools) sweep a broad surface quickly, catch known patterns and are ideal for regression. They quickly find known XSS and injection patterns, open misconfigurations and old components. But they miss business-logic flaws, authorization-bypass chains, multi-step account takeover and context-dependent IDOR, because they do not know what the application is supposed to do. A scanner cannot know the rule "this user should not see this invoice"; only a human who understands the application's workflow finds it. Manual testing fills this gap: the expert understands the workflow and builds chains with human creativity. The two are complementary, not substitutes.

The primary tool: Burp Suite and KAOS

Burp Suite is PortSwigger's web vulnerability scanner and intercepting proxy; it is the industry-standard toolkit for web application penetration testing. It captures, modifies, repeats and automates requests; it is the backbone of manual testing. A tester captures a request with Burp, changes parameters one by one, observes the server's response and builds the vulnerability step by step. Our autonomous engine KAOS adds speed on the discovery and verification side, sweeps a broad surface and flags candidate findings; but every critical finding is verified manually by a human expert and turned into an executable proof.

Common findings

In our field experience the most common findings in web applications are: authorization checked only in the interface and not on the server (not seeing a hidden button does not mean you cannot call that function); predictable or non-expiring password-reset tokens; session tokens not invalidated on logout; verbose error messages leaking database structure; file-upload fields without type and content validation; and outdated libraries. Most of these findings look low on their own, but chained together they lead to account takeover or a data breach.

How findings are reported

Every finding is presented with an executable proof of concept and step-by-step reproduction; false positives are eliminated. For this discipline see verified vulnerabilities and false-positive-free testing. The report includes a risk rating (for example CVSS), business impact and a clear remediation step for each vulnerability; it also provides a plain summary for executives and a detailed section for the technical team. Closure is confirmed with a retest after remediation and a closure report is given.

Frequently Asked Questions

Is a scanner report a penetration test? No. Automated scanning is part of the test; only manual testing and human verification reveal business-logic and authorization flaws. Relying on a scanner alone means missing the most critical vulnerabilities.

Is it tested in production? Preferably on a copy (staging) environment; if production must be tested, scope, time window and data handling are defined in writing, and KVKK obligations are observed for tests touching personal data. For the legal framework see the penetration testing contract and legal authorization.

How often should it be done? At least once a year and after significant application changes; for teams doing continuous delivery, at every major release or more often.

Am I safe enough behind a WAF? No. A WAF is a layer of protection but does not stop business-logic and authorization flaws; a penetration test measures the real risk behind the WAF.

Is my mobile app's API also tested? Yes, web and API tests usually run together; for the mobile side see our mobile application penetration testing.

Sources

To manually test your web application's business logic and authorization layer, contact DSET.