The Complete Checklist to Web App Pentest (OWASP Top 10)

Modern apps power your business, but they also expose it to attackers. Penetration testing helps identify vulnerabilities before attackers could exploit web applications. 

In this blog, we will discuss OWASP top 10 risks and a comprehensive web application penetration testing checklist to effectively test web applications against the OWASP Top 10 security risks.

Understanding OWASP Top 10 Risks

The OWASP Top 10 outlines the most critical security risks to web applications. It serves as an essential guide for developers and security professionals to understand and mitigate the most common vulnerabilities in web applications.

The list is updated every four years. It was last updated in 2021 and the next release is planned in 2025. Security experts use the OWASP Top 10 list to prioritize their security efforts and ensure their web applications are secure. 

The updated OWASP Top 10 vulnerabilities of 2021 witnessed some significant changes with new threats such as insecure design, software, and data integrity failures, and server-side request forgery rising to secure spots amongst the top 10 most critical vulnerabilities of the year.

These updates have made the list a more comprehensive framework for the security of web applications, helping security experts identify and address vulnerabilities more effectively.

A01: Broken Access Control

Broken access control is a serious security flaw where an attacker gains unauthorized access to web applications, sensitive data, or other resources by circumventing standard security procedures. 

This can happen due to poor authorization mechanisms, missing input validation, insufficient encryption, and other similar issues. For example, if a user can view or modify data or perform actions, they should not be able to due to inadequate access controls.

A02: Cryptographic Failures

Cryptographic failures vulnerabilities usually come from outdated protocols, hardcoded keys, or the lack of encryption. When encryption is weak or not used correctly, attackers may read or alter this data. It may put your sensitive information, such as passwords, bank details, and customer records, at risk.  

Examples of cryptographic failures include weak encryption algorithms, insecure key management, use of outdated protocols, and lack of data integrity protection

Using reliable encryption methods, updated libraries, and careful handling of secrets can help minimize cryptographic loopholes.

A03: Injection and XSS

Injection and Cross-site Scripting (XSS) occurs when an attacker injects malicious scripts into the input fields of a trusted or benign website. Through XSS attacks, cybercriminals use web applications to transmit this malicious code as browser scripts to other end users.

Examples of injection attacks include SQL injection, command injection, and XML injection, all of which can result in data theft, data loss, or system compromise. 

Taking advantage of lax security protocols, attackers can sneak scripts in the system and run it in their browser. These issues can be easily avoided by treating all user input as untrusted and controlling how it’s processed.

A04: Insecure Design

Insecure Design is a new category for 2021 OWASP, it is a form of vulnerability that arises from developers and IT security teams foreseeing and assessing potential flaws in the code design phase that may pose a significant threat later on. 

This attack frequently occurs when application developers fail to follow the best secure coding practices when designing their web applications.If a system is built without considering what could go wrong, it often leaves security gaps in the design.

For example, a system that does not follow the principle of least privilege or does not properly segregate duties may be vulnerable to attack. 

Examples include login features that skip validation checks or forms that fail to filter input. Design choices should always be reviewed with security in mind, not just functionality.

A05: Security Misconfiguration

Security misconfigurations are vulnerabilities that occur when the system or web application’s configuration settings are not configured or improperly configured. Such problems frequently emerge when security teams and developers leave the configuration settings on default or perform incorrect configurations.

Security misconfigurations allow attackers to penetrate the system. Therefore, every setup, whether server, app, or database should be regularly reviewed.

Examples of security misconfiguration vulnerabilities include default passwords or settings that are not changed, unsecured ports or services, misconfigured firewalls, or access controls.

Read more about Security Misconfiguration

A06: Vulnerable and Outdated Components

While security patches and updates for software keep them secure against emerging attack vectors, when they no longer receive such support, they become increasingly susceptible to attacks over time. 

The reason for this is most apps use outside tools, code, or libraries during the software development phase. Some of these components aren’t updated, patched, or no longer supported, opening security gaps in the system.
Such vulnerabilities caused by exposed software components are known as Vulnerable and Outdated Components. The best way to avoid such risks is to keep a list of components and update them regularly.

A07: Authentication Failures

Identification and authentication failures occur when the applications fail to authenticate and verify a user’s identity, who then goes on to access the system assuming a false unverified identity. This vulnerability commonly occurs with systems and applications that don’t implement effective authentication and session management functions.

Examples of identification and authentication failures include weak or easily guessable passwords, lack of two-factor authentication, improper session management and insufficient user validation. 

Such gaps can be minimized by implementing robust password handling mechanisms, two-step verification, or enforcing proper session rules.

A08: Software and Data Integrity Failures

Software and data integrity failures happen when attackers gain access to sensitive user and application information through integrity violations from unsecured infrastructure and code. 

The most common instances of this vulnerability are when web applications heavily rely on libraries, modules, and plugins from untrusted third-party sources, repositories, and content delivery networks (CDNs).

Testing for this risk involves checking the input validation mechanisms, cryptographic controls, and other security controls designed to prevent data tampering and ensure data integrity. 

This can be done using automated tools to inject malicious inputs or manually reviewing the source code and testing the application’s response to various inputs.

A09: Logging and Monitoring Failures

Security Logging and Monitoring Failures are vulnerabilities where attackers bypass or disable logging mechanisms to cover their tracks and mask their malicious activity within the application. 

In such instances, it becomes increasingly challenging for security teams to detect, track, and respond to attackers and their exploits. This can be done using automated tools to generate various security events or manually reviewing the application’s logs and monitoring systems.  

Logging and monitoring failures occur owing to the lack of recording, logging, and analyzing security-relevant events. If an attack happens but no one notices, it keeps going.

Missing logs make it easy for problems to go undetected. Important actions and errors should be recorded in one place. Security teams need alerts when something unusual happens, not after the damage is already done.

A10: Server-Side Request Forgery (SSRF)

Server-side request forgery (SSRF) is a vulnerability that allows the attacker to induce the server-side application to make illegitimate requests to forced locations. Through this vulnerability, attackers may be able to strongarm the server to connect to external systems to leak sensitive data such as login and authorization credentials.

Some systems let users input a URL and then fetch it on their behalf. If not handled carefully, attackers can trick the server into connecting to places it shouldn’t.

This might include internal apps, cloud settings, or other protected services. To block this, restrict where the system is allowed to connect and always check user-supplied URLs.

Read more about Server-Side Request Forgery (SSRF)

Web Application Penetration Testing Checklist

Without any further delay, let us dive into the web application penetration checklist to conduct a thorough web app penetration testing:

1. Information Gathering:

• Go through the application manually. Visit every page and use all available features to understand how it works and how users interact with it.
• Use a spidering or crawling tool like Burp Suite or OWASP ZAP to discover hidden files, directories, and pages that aren’t directly linked.
• Look for exposed files such as robots.txt, sitemap.xml, or .DS_Store. These often reveal unlisted paths or internal information that should not be public.
• Check cached or archived pages using Google Cache or the Wayback Machine. These may contain old or sensitive content that has since been removed from the live site.
• Identify the technologies behind the site—frameworks, server software, and specific libraries. Use HTTP headers, JavaScript files, and fingerprinting tools to gather this data.
• List all input points, such as forms, file upload fields, and API endpoints. Intercept their requests using tools to understand how data is sent and handled.
• Look for business logic issues, unused API calls, or any hardcoded credentials or tokens.
• Create test accounts to simulate different user roles, and compare what each role can see or do. This helps uncover broken or missing access controls.

2. Configuration Management: 

• Confirm that the web server does not support resource manipulation methods from the internet (such as PUT and DELETE).
• Determine whether the site is virtually hosted, as additional sites may be vulnerable and could compromise the base server.
• Verify that known vulnerabilities with available vendor patches are not present.
• Make sure no backup files of source code are available on the public-facing part of the application.
• Address common web server configuration issues, such as directory listings and leftover sample files.
• Check that web server components like FrontPage Server Extensions or Apache modules do not introduce security vulnerabilities.
• Detect the presence of common directories within the application root (such as /backup and /admin).
• Check for language or application defaults, such as environmental quirks or the availability of default files and loaded modules.
• Ensure that administrative interfaces to infrastructure components (e.g., web servers, application servers) are not accessible from the internet.
• Ensure that administrative interfaces to the application itself are not publicly exposed.

3. Authentication:

• Verify that usernames and passwords are transmitted over an encrypted channel.
• Check for default account names and passwords still in use.
• Avoid using public identifiers like email addresses or SSNs as usernames.
• Enforce password complexity to make brute-force or guessing attacks difficult.
• Prevent passwords from being sent to users via email.
• Lock user accounts temporarily after a set number of failed login attempts.
• Avoid using special meta characters in passwords. 

4. Access Control: 

• Make sure access control rules are enforced correctly.
• Users should not be able to gain unauthorized access or unlock hidden features by modifying inputs, query strings, cookies, or JavaScript values.
• Verify that every protected resource performs a proper authorization check before it is displayed to the user.
• After logging in, test whether a user can manipulate session data—like user IDs or account numbers—to access or act on another person’s account.
• Try visiting protected pages directly, either without logging in or by bypassing the login screen. These pages should be completely inaccessible without valid authentication.
• Some applications follow a strict sequence of actions, such as during checkout or account setup. Confirm that users cannot skip steps or jump ahead by tampering with requests.

5. Authorization: 

• Check for path traversal by entering payloads like ../, %2e%2e/, or ..\\ in input fields that handle file names or paths.
• Try accessing sensitive files such as `/etc/passwd ` or ` web.config `  to confirm whether directory access is properly restricted
• Attempt to bypass authorization by modifying roles or parameters in the request.
• Test whether valid tokens or session cookies from one user can be reused in another session.
• Look for horizontal access control flaws by changing IDs in requests. 
• Try visiting internal or restricted routes without logging in to verify that unauthorized access is blocked.
• Every sensitive endpoint or API must enforce both authentication and proper permission checks on the server side.

6. Session Management:

• Disable HTTP methods like PUT and DELETE on the web server unless they are explicitly required.
• Check if the application is virtually hosted. Other sites sharing the same server could be vulnerable and pose a risk to the main application.
• Ensure all software and components are fully patched and up to date.
• Look for backup copies of source code (e.g., .bak, .zip, .old) that may have been accidentally left in publicly accessible directories.
• Fix any web server misconfigurations, including disabling directory listings and removing default files or sample content.
• Review server components such as Apache modules or legacy tools like FrontPage Server Extensions for potential vulnerabilities.
• Check for sensitive directories like /backup, /admin, or /test, which are often overlooked and may expose configuration files or credentials.
• Restrict access to all administrative panels and infrastructure tools.

7. Error Handling:

• Trigger various errors (e.g., invalid input, broken URLs, forced exceptions) and observe how the application responds.
• Verify that error messages do not expose stack traces, database dumps, or internal system details.
• Return only generic error messages to users, while logging detailed errors securely for administrative access.
• Check whether the application returns different responses for an invalid username versus an incorrect password (e.g., “User does not exist” vs. “Password incorrect”).
• Confirm that all authentication failures return a single, generic message such as “Invalid username or password” to avoid leaking information about user accounts.

8. Data Protection:

• Check that no sensitive data is rendered in visible form fields.
• Verify browser caching is disabled for sensitive pages.
• Confirm all stored data is encrypted.
• Verify only secure SSL/TLS versions (TLS 1.2 or higher) are enabled.
• Disable SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1.
• Ensure all anonymous key exchange methods (e.g., ADH) are disabled.
• Remove support for RC2, DES, and other weak algorithms.
• Confirm encryption key length is at least 128 bits.
• Validate that encryption keys are securely stored and rotated.
• Confirm the digital certificate is signed by a trusted CA.

9. Input Validation:

• Prevent any part of the application from executing scripts included in user input.
• Reject SQL commands submitted through user input to protect against SQL injection.
• Block execution of operating system commands originating from user-supplied data.
• Disallow processing of LDAP commands provided by users.
• Sanitize all inputs to prevent storage or reflection of malicious script code.

10. Buffer Overflow

• Protect the application from any buffer overflow vulnerabilities.
• Safeguard the application against heap overflow conditions.
• Prevent the application from being susceptible to stack overflows.
• Eliminate the risk of format string overflows within the application.

Bottomline

Testing web applications for security issues helps catch problems early, before they become serious. Fixing weak spots in login systems, session handling, and data flow lowers the risk of data leaks. 

Doing regular checks and controlled attacks keeps the system ready for new types of threats. When teams follow clear security steps and stay alert, they protect both users and the business. If you are interested to know more about our penetration testing services, reach out to us.

References resources: 

OWASP Penetration Testing Check List

OWASP Web Security Testing Guide | OWASP Foundation

FAQs