Web Application Penetration Testing: OWASP Top 10 Methodology

Web applications are the front door of modern business and the primary target for attackers. According to the Verizon 2025 Data Breach Investigations Report, web application attacks were involved in 68% of breaches with external threat actors. The OWASP (Open Web Application Security Project) Top 10 provides the definitive framework for identifying and testing the most critical web application security risks. This guide walks through each OWASP Top 10 vulnerability, explains how professional penetration testers evaluate them, and provides actionable remediation strategies.

The OWASP Top 10 (2021): Current Landscape

The OWASP Top 10 was last updated in 2021 and remains the authoritative reference for web application security testing. The 2021 edition introduced significant changes from the 2017 version, reflecting the evolving threat landscape:

A01: Broken Access Control

Broken access control moved from fifth place in 2017 to the number one position in 2021. OWASP found that 94% of applications tested had some form of broken access control, with over 318,000 Common Weakness Enumerations (CWEs) mapped to this category.

How Testers Evaluate It

• Horizontal privilege escalation: Attempting to access other users' data by modifying identifiers (e.g., changing user_id=123 to user_id=124 in API requests)
• Vertical privilege escalation: Trying to access administrative functions with a regular user account
• IDOR testing: Manipulating direct object references in URLs, API parameters, and form fields
• Force browsing: Accessing restricted pages by directly entering URLs without authentication
• CORS misconfiguration: Testing whether cross-origin resource sharing policies allow unauthorized access

Real-World Impact

In 2024, a major European healthcare platform suffered a breach affecting 2.3 million patient records due to an IDOR vulnerability that allowed any authenticated user to access other patients' medical records by modifying a numeric ID in the API endpoint.

Remediation

Implement server-side access control checks on every request. Use role-based access control (RBAC) with the principle of least privilege. Deny access by default and log all access control failures for monitoring.

A02: Cryptographic Failures

Previously known as "Sensitive Data Exposure," this category focuses on failures related to cryptography that lead to exposure of sensitive data.

How Testers Evaluate It

• Checking for data transmitted in clear text (HTTP, SMTP, FTP)
• Verifying TLS configuration (protocol versions, cipher suites, certificate validity)
• Testing for weak or deprecated cryptographic algorithms (MD5, SHA1, DES)
• Examining password storage mechanisms (looking for plain text, weak hashing)
• Checking for sensitive data in URLs, logs, or error messages

Remediation

Classify data by sensitivity level and apply appropriate controls. Use TLS 1.2+ for all data in transit. Store passwords using strong adaptive hashing functions (bcrypt, Argon2). Never store sensitive data unnecessarily.

A03: Injection

Injection flaws including SQL injection, NoSQL injection, OS command injection, and LDAP injection remain among the most dangerous web vulnerabilities. While the incidence has decreased from earlier years, injection attacks still account for some of the most devastating breaches.

How Testers Evaluate It

• SQL injection: Inserting SQL syntax into input fields, URL parameters, cookies, and HTTP headers
• Cross-site scripting (XSS): Injecting JavaScript payloads into reflected, stored, and DOM-based contexts
• Command injection: Testing inputs that may be passed to system commands
• Template injection: Testing server-side template engines for code execution
• Header injection: Testing HTTP header values for injection opportunities

Remediation

Use parameterized queries (prepared statements) for all database interactions. Implement input validation using an allowlist approach. Apply context-appropriate output encoding. Use ORMs where possible, but verify they are configured securely.

A04: Insecure Design

New in the 2021 edition, this category addresses fundamental design flaws that cannot be fixed by perfect implementation. It focuses on risks related to missing or ineffective security controls at the design level.

How Testers Evaluate It

• Reviewing business logic for bypass opportunities (e.g., skipping payment steps in e-commerce)
• Testing rate limiting on sensitive operations (password reset, login, API calls)
• Evaluating trust boundaries and data flow patterns
• Assessing whether security requirements were considered in the application architecture

Remediation

Integrate threat modeling into the development lifecycle. Establish and use a library of secure design patterns. Implement rate limiting and resource constraints at the design level.

A05: Security Misconfiguration

Found in 90% of applications tested, security misconfigurations are pervasive. This includes default configurations, incomplete configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages.

How Testers Evaluate It

• Checking for default credentials on admin panels, databases, and services
• Reviewing HTTP security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
• Testing for directory listing and information disclosure
• Verifying that unnecessary features, ports, and services are disabled
• Checking error handling for stack traces and debug information

Remediation

Implement a repeatable hardening process for all environments. Remove unused features and frameworks. Review and update configurations regularly. Use security headers and implement a Content Security Policy.

A06: Vulnerable and Outdated Components

According to Sonatype's 2025 State of the Software Supply Chain report, the average application contains 148 open-source dependencies, and 23% of those have known vulnerabilities. Organizations take an average of 158 days to patch known component vulnerabilities.

How Testers Evaluate It

• Identifying all client-side and server-side components and their versions
• Checking components against CVE databases for known vulnerabilities
• Testing for outdated JavaScript libraries with known exploits
• Evaluating the dependency supply chain for compromised packages

Remediation

Implement continuous component inventory management. Use software composition analysis (SCA) tools. Establish a patch management process with defined SLAs for critical vulnerabilities.

A07: Identification and Authentication Failures

This category covers weaknesses in authentication mechanisms, session management, and identity verification.

How Testers Evaluate It

• Testing for credential stuffing and brute force resistance
• Evaluating password policies (complexity, length, common password checking)
• Checking session management (session fixation, session timeout, secure cookie flags)
• Testing multi-factor authentication bypass techniques
• Verifying password recovery flows for information disclosure

Remediation

Implement multi-factor authentication. Enforce strong password policies and check against breached password databases. Set appropriate session timeouts and regenerate session IDs after authentication.

A08-A10: Additional Critical Categories

A08: Software and Data Integrity Failures

Tests focus on verifying CI/CD pipeline integrity, checking for unsigned or unverified software updates, and assessing deserialization vulnerabilities. The SolarWinds attack demonstrated the devastating potential of supply chain integrity failures.

A09: Security Logging and Monitoring Failures

Testers evaluate whether the application logs authentication events, access control failures, and input validation failures. According to IBM Security (2025), organizations without proper logging take an average of 277 days to identify a breach, compared to 186 days for those with comprehensive monitoring.

A10: Server-Side Request Forgery (SSRF)

SSRF attacks have increased significantly with cloud adoption. Testers check whether the application makes server-side requests based on user-supplied URLs, attempting to access internal services, cloud metadata endpoints (169.254.169.254), and internal network resources.

Essential Tools for Web Application Pentesting

Getting Your Web Application Tested

A professional web application penetration test typically costs EUR 3,000-18,000 depending on application complexity, number of user roles, and API endpoints. Testing takes 3-10 business days, with a comprehensive report delivered 5-7 business days after testing concludes.

Orizon Fireline provides comprehensive web application penetration testing aligned with the OWASP Testing Guide v4.2, covering all Top 10 categories plus business logic testing, API security assessment, and authentication mechanism evaluation. Our reports include executive summaries, detailed technical findings with CVSS scores, and prioritized remediation roadmaps.

For an overview of all penetration testing types and how web application testing fits into a broader security program, see our guide on 7 types of penetration testing.