Reports

Technical details

(no additional sections)

Web application summary

Web application summary
Web application details

API1

Broken Object Level Authorization

APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface of Object
Level Access Control issues. Object level authorization checks should be considered in every function
that accesses a data source using an ID from the user.

API2

Broken Authentication

Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise
authentication tokens or to exploit implementation flaws to assume other user's identities temporarily
or permanently. Compromising a system's ability to identify the client/user, compromises API security
overall.

API3

Broken Object Property Level Authorization

This category combines API3:2019 Excessive Data Exposure and API6:2019 - Mass Assignment,
focusing on the root cause: the lack of or improper authorization validation at the object property level.
This leads to information exposure or manipulation by unauthorized parties.

API4

Unrestricted Resource Consumption

Satisfying API requests requires resources such as network bandwidth, CPU, memory, and storage.
Other resources such as emails/SMS/phone calls or biometrics validation are made available by service
providers via API integrations and paid for per request. Successful attacks can lead to Denial of Service
or an increase of operational costs.

API5

Broken Function Level Authorization

This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open
cloud storage, misconfigured HTTP headers and verbose error messages containing sensitive
information.

API6

Unrestricted Access to Sensitive Business Flows

APIs vulnerable to this risk expose a business flow - such as buying a ticket, or posting a comment -
without compensating for how the functionality could harm the business if used excessively in an
automated manner. This doesn't necessarily come from implementation bugs.

API7

Server-Side Request Forgery

Server-Side Request Forgery (SSRF) flaws can occur when an API is fetching a remote resource without
validating the user supplied URI. This enables an attacker to coerce the application to send a crafted
request to an unexpected destination, even when protected by a firewall or a VPN.

API8

Security Misconfiguration

APIs and the systems supporting them typically contain complex configurations, meant to make the
APIs more customizable. Software and DevOps engineers can miss these configurations, or don't follow
security best practices when it comes to configuration, opening the door for different types of attacks.

API9

Improper Inventory Management

APIs tend to expose more endpoints than traditional web applications, making proper and updated
documentation highly important. A proper inventory of hosts and deployed API versions also are
important to mitigate issues such as deprecated API versions and exposed debug endpoints.

API10

Unsafe Consumption of APIs

Developers tend to trust data received from third-party APIs more than user input, and so tend to adopt
weaker security standards. To compromise APIs, attackers go after integrated third-party services
instead of trying to compromise the target API directly.

M01

Improper Credential Usage

Improper Credential Usage refers to vulnerabilities that arise from security weakness in mobile applications. These vulnerabilities can be exploited through hard coded credentials in the code or improper management of credential, leading to sever technical and business impacts.

M02

Inadequate Supply Chain Security

A supply chain consists of the organizations, individuals, activities, resources, and technologies involved in creating and distributing a product or service from supplier to customer. Attackers can exploit vulnerabilities in a mobile app’s construction by inserting malicious code during development. This can lead to data theft, user surveillance, or full control of the device. Detecting this vulnerability is challenging, but the technical an business impacts are severe.

M03

Insecure Authentication/Authorization

Ensuring secure authentication and session management in mobile applications is crucial to prevent unauthorized access to sensitive data and backend systems. Mobile devices, offering biometric authentication, must enforce these measures constantly. Insecure authorization processes risk exposing unauthorized data or functions, particularly when decisions are made locally rather than on centralized servers. While offline access is legitimate requirement, it introduces security challenges. Secure communication with backend systems or smart devices via various protocols like Wi-Fi or Bluetooth is essential to safeguard data integrity and user privacy in mobile applications.

M04

Insufficient Input/Output Validation

Insufficient validation of external data in mobile apps, such as user inputs, can lead to serious threats like SQL injection,  cross-site scripting (XSS), and command injection. These vulnerabilities may result in unauthorized access, data manipulation, and compromise of the app’s functionality and backend systems. While easily detected, they can have severe technical and business impacts.

M05

Insecure Communication

Most mobile applications require ways to communicate with backend systems or local smart devices, either through direct client- server communication , or through an intermediate API. It is pivotal that communication takes place in a secure way. Regardless of the type of transmission, including among others: Wi-Fi, Bluetooth, NFC, and Cellular communication.

M06

Inadequate Privacy Controls

Application-specific privacy controls protect Personally Identifiable Information (PII). such as names, addresses, credit card details, emails, IP-addresses, and sensitive on health, religion, sexuality, and political opinions. This information is valuable to attackers for identity theft, fraud, financial misuse, blackmail, and data damage.

M07

Insufficient Binary Protections

Reverse engineering mobile apps can expose critical information and lead to security breaches. Attackers may exploit this by distributing maliciously modified versions of apps through third-party stores, resulting in data theft and reputational damages. While all mobile apps are vulnerable to code tampering, evaluating the effectiveness of Root and Jailbreak detection can mitigate these risks. Poor code quality, although not a direct security issue, can create vulnerabilities exploited by malware and phishing, emphasizing the need for robust security controls in mobile app development.

M08

Security Misconfiguration

Extraneous, or irrelevant, functionality is especially interesting to identify and further scrutinize for an attacker. Such 4 RESTRICTED Author: GL/OffSec/FLA functionality within a mobile app may allow an attacker to identify hidden functionality in backend systems. An attacker can typically exploit extraneous functionality directly from their own systems without any involvement by end-users. These functionalities often go by unnoticed to developers, as the extraneous functionality are often not exposed through, or well-hidden within, the user interface.

M09

Insecure Data Storage

Insecurely stored data by the application may provide a platform of attack for adversaries or may expose Personally Identifiable Information (PII) or other sensitive information stored within the application, elsewhere on the mobile device or cloud storage.

M10

Insufficient Cryptography

Insecure cryptography methods enable attackers to breach systems and access protected information. They may attempt to decipher encryption codes, use brute force to guess passwords, or exploit weaknesses in encryption setup. This allows them to read encrypted data, manipulate encryption processes, or gain unauthorized access to accounts, leading to data leaks and falsification of information. Attackers include those attempting to decrypt data for unauthorized access, insiders misusing access or sharing keys, government entities for espionage, cyber criminals exploiting weak encryption for theft or fraud, and hackers discovering flaws in encryption methods.

High (H)

Specialized access conditions exist. For example:
In most configurations, the attacking party must already have elevated privileges or spoof additional systems in addition to the attacking system (e.g., DNS hijacking).
The attack depends on social engineering methods that would be easily detected by knowledgeable people. For example, the victim must perform several suspicious or atypical actions.
The vulnerable configuration is seen very rarely in practice.

Medium (M)

The access conditions are somewhat specialized; the following are examples:
The attacking party is limited to a group of systems or users at some level of authorization, possibly untrusted.
Some information must be gathered before a successful attack can be launched.
The affected configuration is non-default, and is not commonly configured (e.g., vulnerability present when a server performs user account authentication via a specific scheme, but not present for another authentication scheme).
The attack requires a small amount of social engineering that might occasionally fool cautious users (e.g., phishing attacks that modify a web browser's status bar to show a false link, having to be on someone's "buddy" list before sending an IM exploit)

Low (L)

Specialized access conditions or extenuating circumstances do not exist. The following are examples:
The affected product typically requires access to a wide range of systems and users, possibly anonymous and untrusted (e.g.,Internet-facing web or mail server).
The affected configuration is default or ubiquitous.
The attack can be performed manually and requires little skill or additional information gathering.
The "race condition" is a lazy one (i.e., it is technically a race but easily winnable).

Local (L)

 Vulnerability exploitable with only local access requires the attacker to have either physical access to the vulnerable system or a local (shell) account. Examples of locally exploitable vulnerabilities are peripheral attacks such as Firewire/USB DMA attacks, and local privilege escalations (e.g., sudo).

Adjacent Network (A)

Vulnerability exploitable with adjacent network access requires the attacker to have access to either the broadcast or collision domain of the vulnerable software. Examples of local networks include local IP subnet, Bluetooth, IEEE 802.11, and local Ethernet segment.

Network (N)

A vulnerability exploitable with network access means the vulnerable software is bound to the network stack and the attacker does not require local network access or local access. Such vulnerability is often termed "remotely exploitable". An example of a network attack is an RPC buffer overflow.

Multiple (M)

Exploiting the vulnerability requires that the attacker authenticate two or more times, even if the same credentials are used each time. An example is an attacker authenticating to an operating system in addition to providing credentials to access an application hosted on that system.

Single (S)

One instance of authentication is required to access and exploit the vulnerability.

None (N)

Authentication is not required to access and exploit the vulnerability.

Partial (P)

There is considerable informational disclosure. Access to some system files is possible, but the attacker does not have control over what is obtained, or the scope of the loss is constrained. An example is a vulnerability that divulges only certain tables in a database.

Complete (C)

There is total information disclosure, resulting in all system files being revealed. The attacker is able to read all of the system's data (memory, files, etc.)

None (N)

There is no impact to the confidentiality of the system.

Partial (P)

Modification of some system files or information is possible, but the attacker does not have control over what can be modified, or the scope of what the attacker can affect is limited. For example, system or application files may be overwritten or modified, but either the attacker has no control over which files are affected or the attacker can modify files within only a limited context or scope.

Complete (C)

There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the entire system being compromised. The attacker is able to modify any files on the target system.

None (N)

There is no impact to the integrity of the system.

Partial (P)

There is reduced performance or interruptions in resource availability. An example is a network-based flood attack that permits a limited number of successful connections to an Internet service.

Complete (C)

 There is total information disclosure, resulting in all system files being revealed. The attacker is able to read all of the system's data (memory, files, etc.)

None (N)

There is no impact to the availability of the system.