Pentest: Which Components Should Be Considered First?

Every system has vulnerabilities - absolute security does not exist. Penetration testing helps you identify and remediate those vulnerabilities. However, modern applications are becoming increasingly complex: beyond the core application, additional functionality is typically integrated from third-party providers via APIs. Since resources for penetration testing are limited, many organizations face a critical question: Which components of their software are most at risk and should therefore be tested first?

Systematically Assess Vulnerabilities with the CVSS

Every system has vulnerabilities - but not every vulnerability is equally critical.
Beyond the access vector, complexity, and authentication requirements, factors such as the impact on confidentiality, integrity, and availability also play a role in vulnerability assessment.

The Common Vulnerability Scoring System (CVSS) is widely used for this purpose. It enables organizations to quantitatively express the vulnerabilities in their architecture. Each score corresponds to one of four severity categories:

Critical Severity

Critical vulnerabilities allow attackers to execute arbitrary code on the target system or access sensitive data. Common examples include BOLA, remote code execution, and command injections.

High-severity vulnerabilities allow attackers to access an application's resources and data, enabling the theft of sensitive information. A well-known example is SQL injection, where the attacker gains access to the system's database through input fields. Unlike critical vulnerabilities, high-severity vulnerabilities alone can never lead to the disclosure of all data. To achieve that, attackers must find additional attack vectors.

Medium Severity

Medium-severity vulnerabilities can most often be traced to configuration errors - for example, a faulty SSL certificate. These can allow attackers to access sensitive information. However, exploiting such a vulnerability places high demands on the attacker. In the case of an invalid certificate, for instance, the attacker must be in a specific location to intercept data at the right moment.

Low Severity

Low-severity vulnerabilities typically result from configuration errors or the accidental disclosure of information. On their own, they are unlikely to cause significant damage. However, they can serve as a stepping stone for attackers to exploit more severe vulnerabilities. A common example is version number disclosure: if a website reveals the version of an application, an attacker can perform targeted vulnerability mapping. If a known vulnerability exists for that specific version, they can leverage it to gain access to the system.

Which Components Are at Risk?

The categorization of vulnerabilities provides clear guidance on how to prioritize penetration testing efforts.

Based on severity levels, certain areas of the software architecture are more vulnerable than others. Mobile applications are affected by vulnerabilities up to high severity at most. This means an attacker can target individual users but cannot access all the data in the system.

Modern applications are not built from scratch. Every web application relies on external services to integrate essential standard functionality that would be impractical or impossible to develop in-house - such as captchas, credit card payments, or email address validation. These API interfaces, however, can harbor critical vulnerabilities that jeopardize the entire system. The reason is that an API interface, by its very nature, reaches deep into the system. Anyone who gains access to it effectively holds a master key.

BOLA: The Number One API Vulnerability

The most significant vulnerability in API interfaces today is Broken Object Level Authorization (BOLA). This is the finding of the Open Web Application Security Project OWASP in its report on the top 10 API security risks.

BOLA has been responsible for numerous high-profile attacks, with victims including Telekom and Apple. The vulnerability relates to authorization flaws in the API interface. A well-known example is the vulnerability discovered in the ride-hailing company Uber's app, which came to light in 2019.

Uber requested the user's email address and phone number and validated the format. When the email address and phone number were swapped, Uber's API returned an error message containing the UUID - the user's unique identifier. Through this vulnerability, it was possible to obtain any user's UUID based on their phone number or email address.

Prioritize Penetration Testing: Check the API First

For most applications, it makes sense to test the API interface first. Especially in the context of mobile apps, this is the only area where critical-severity vulnerabilities can arise. In the worst-case scenario, an attacker could gain access to all user data. Beyond the resulting economic damage, the reputational harm caused by such a vulnerability can be equally devastating.

A scoring system like the CVSS helps you assess existing threats and weigh them against each other effectively. With the CVSS calculator from FIRST.org, you can calculate the severity of your vulnerabilities according to CVSS.