How to understand your mobile app penetration test report

If you’re shipping a mobile app to market, there’s a good chance you’ll get an external pen test report before you’re ready to release. 

There are plenty of good reasons to do so. After all, pen testers are trained to target your app in much the same way a hacker would, making this a hugely valuable way to understand its overall security posture. 

When the report comes back, you’ll generally have a long list of vulnerabilities, issues, and bugs. This is completely normal. But before you can go to market, you’ll have to resolve the most critical issues and ensure the app is safe, secure, and compliant. 

Doing that is easier said than done. To do so, you’ll have to make a number of strategic decisions that no pen test report can make for you. So where do you start? 

What are the most common vulnerabilities in mobile apps? 

Before we can consider how to prioritize vulnerabilities, it’s first helpful to understand them. After all, there are a whole range of different types of issues that a mobile app penetration test report might identify—and not all of them are equally dangerous. 

It’s therefore important to understand what these vulnerabilities involve and how a malicious actor would exploit them. We can split these up into issues affecting the client and server side of the app: 

Client side

This includes any issues affecting the user-facing app, including:

• Insecure data storage: This includes issues like hardcoded credentials, poor encryption policies, or insecure storage locations, all of which enable hackers to access accounts and sensitive data. Sometimes, they may need to root/jailbreak the device to exploit the vulnerability, other issues (i.e. hardcoded credentials, insecure storage locations) might not even require them to do that. 

• Unencrypted communications: Protocol-related issues are another common feature of pen test reports. These include using plaintext HTTP (instead of HTTPs/TLS), not properly validating SSL certificates, or relying on deprecated protocols. All of these issues can lead to loss of valuable data in transit and man-in-the-middle attacks.
• Insufficient input validation: This occurs when messages from either the system or other apps aren’t properly validated, allowing the hacker to inject code or redirect traffic. A common example is when the hacker replaces the URL in messages from the browser or system designed to redirect the user to that page. Instead, the attacker can redirect the user to a site of their own choosing.
• Inadequate supply chain security: This includes not properly validating any third-party elements that the app might incorporate, including third-party libraries and resources. If you don’t effectively validate third-party suppliers, you risk introducing any security issues those third-party elements already include.

Server side

As the name would suggest, these relate to any issues on any servers your company manages., including on-premises and cloud-based infrastructure. These include:

• Authorization issues: A range of issues around how the server authorizes end users. The most common of these is IDOR, where authorization is done through parameters that the user themselves can edit, enabling non-privileged users to access resources they should not be able to, simply by editing text-based fields. 

• Poor authentication: This includes weak credential policies, such as a lack of controls around duplicated or weak passwords, as well as not having multi-factor authentication. This makes it easier for hackers to guess or brute force a password. It can also involve poor management of session tokens, allowing hackers to piggyback on an existing session without needing passwords.

• Insecure cryptography: Including poor or no password encryption in the database, weak encryption of session tokens, and use of outdated protocols. This can lead the hacker to access credentials and session tokens, or (in the case of protocols) lead to data loss in transit.

• Configuration flaws: This includes several loosely related examples of poor best practice, including disclosing sensitive information in error messages, using publicly accessible admin panels or APIs, weak security settings for databases, lack of DoS/DDoS protections, and more. 

How to interpret app pen test results

When you receive your pen test report, you’ll probably find a long list of vulnerabilities, ranked from critical to low. 

Your first instinct will likely be to resolve the most critical issues first and work your way down the list. This is usually the right policy. But there are several other factors you’ll also need to take into account:

Time vs. criticality

Some vulnerabilities will take longer to remediate than others. Therefore, an issue with lower criticality might be very quick to resolve, making it easier to prioritize it outright. 

Understanding your infrastructure

Pen testing companies have a whole range of metrics they use to decide how risky a particular vulnerability is. But generally, they aren’t experts on your infrastructure and might not know the impact of a specific vulnerability on your app, server, or architecture. 

For example, a vulnerability might be labeled high-risk by the vulnerability report. But if the exploit would target a non-critical asset, it could be less dangerous than the pen test suggests. 

Test vs. production

Pen testers will generally carry out their analyses on test rather than production builds. This generally involves disabling many of the security protections that would be present when the final app is released. This could include code obfuscation, firewalls, and SSL-pinning features. 

None of these features are designed to remediate specific vulnerabilities. But they do make it much more difficult for hackers to understand and successfully exploit them. If so, this would make the danger lower than it might initially appear. Pen testers generally take this into account, but not always. 

Generally, it’s helpful to provide the pen testing company with a test environment that’s as close as possible to the production environment. This will reduce the impact of these issues—though, of course, it’s not always possible.

Differing metrics

Pen testing companies use different metrics and standards to identify vulnerabilities and assign risk. While there are industry standards (like the common vulnerability scoring system), these aren’t used by everyone. 

At the same time, companies won’t even necessarily use the same terms to label criticality. Some will rank four levels (critical, high, medium, and low), others only three (critical, medium, and low). Here, the relative risk of medium is going to differ, depending on which version is being used.  

There’s no objective standard here and the results will generally differ from company to company. Therefore, it’s important to take this into account when deciding on your strategy.

How to prioritize vulnerabilities and get your app to market

So you’ve received your pen test report. At this point, your priority is to get your app ready to ship to market as quickly as you can, without sacrificing safety or compliance. 

So how do you get from here to there? 

Obviously, you’ll need to remediate a whole range of vulnerabilities before the app is ready. But it’s not quite as simple as starting at the top of the list and working your way down. 

To work out your game plan, you’ll need to work with an in-house technical specialist who can interpret the pen test report and collaborate closely with the company that produced it. During the discussion, there are several key decisions you’ll need to make to determine what needs remediating and when:

• What is the relative criticality? Discuss the factors we explained in the last section to decide how critical each vulnerability is to your specific app and infrastructure. In special cases, vulnerabilities labeled high or critical by the pen test report might not be as dangerous as they first appear.

• Where do we draw the line between blocking issues? The most critical issues will need to be resolved before going to market, but this isn’t the case for everything. Therefore, you’ll need to decide where to draw the line and what vulnerabilities can be resolved later or simply aren’t critical enough to worry about at all. 

• Are there any compliance requirements? In some industries and jurisdictions, there will be specific requirements around vulnerabilities that need to be resolved before you can go to market. In this case, anything that’s a compliance requirement must be considered a blocking issue. 

• What resources do you have? Debugging and remediating vulnerabilities takes time. When prioritizing the most important to resolve, it’s important to understand what resources you have available to do so.  

• How will you balance time against criticality? It’s helpful to take into account the time taken to resolve when deciding what to prioritize. A lower-risk vulnerability might be so quick to remediate that it’s worth prioritizing anyway. 

App shielding: How to keep your app safe after you’ve gone to market

The results of your pen test might seem daunting at first, but it’s nothing out of the ordinary. Very few apps will make it to this stage without a whole swathe of issues to resolve. 

But while remediating vulnerabilities is important, it’s not the only tool in your arsenal to keep your app safe. In fact, products like application shielding aim to make it as difficult as possible for hackers to understand and exploit any vulnerabilities in your app. 

Application shielding uses a range of techniques that make your apps resistant to a whole range of attacks. This includes: 

• Code obfuscation: Aims to modify both the byte and binary code of your app, making it more difficult for the hackers to access or reverse engineer the underlying code through static analysis. 
• Runtime protections: Help protect your code from attempts to analyze the app’s behavior during runtime. This protects against issues like intrusion, tampering, reverse engineering, and more.