My company is looking to work with a potential client's backend provider in order to make an app for them. To do this, we need to use their API. We've spoken to this company and they are worried about security and so have said that they will only let us launch the app if we have it penetration tested by a third party.

The app will allow users to login and access their financial information so it makes sense that they want to make sure everything is secure but, from my understanding, "penetration testing" doesn't really make sense for a mobile app. Is this correct? What can we do to satisfy them that the app is secure? Is there a name for a kind of standard app security test that could be performed by a third party?

  • price will depend on a lot of factors (including what country the tester is in) so I removed that part
    – schroeder
    Commented Sep 16, 2018 at 20:08
  • Many testers use the term "penetration testing" to mean "security testing" or "security assessment".
    – schroeder
    Commented Sep 16, 2018 at 20:09
  • Agreed, "penetration testing" probably isn't the right word for a mobile app, but it makes it clear that they're looking for 3rd party black box testing, rather than a source code or design review from the developer. Commented Sep 16, 2018 at 20:20

2 Answers 2


Speaking as a former security consultant who regularly performed penetration tests of third-party mobile apps, it absolutely makes sense. In practice, mobile apps are a bit less amenable to black-box pentesting than some other types of app (such as web apps or kernel-mode drivers), but there's a lot you can do even black-box (and more with white-box, though reverse-engineering most Android apps is so easy they are practically always white-box).

A few common security issues we found:

  • Apps not doing TLS validation correctly (for example, allowing self-signed certs or even arbitrary invalid certs).
  • Apps that had vulnerable entry points (file associations, URI schemes, share contracts, or other ways to programmatically invoke them and then make them do something they shouldn't).
  • Apps that used out-of-date libraries or SDKs with known vulnerabilities.
  • Apps that used web views with insecure JavaScript bridges.
  • Apps that used HTTP instead of HTTPS sometimes.
  • Apps that used web views but didn't lock down their paths or JS execution, and were vulnerable to web app vulns and/or to phishing.
  • Apps that stored secrets (credentials, tokens, private data, etc.) in plain text and/or in readable locations.
  • Apps that stored keys or other secrets (for example, an API key for a web service) in their binaries, as though an attacker can't reverse engineer the app to find it.
  • Apps that used native code insecurely, and had memory corruption bugs.
  • Apps that used cryptography incorrectly and therefore insecurely.

There are plenty more that can crop up, though those are some of the most common and/or severe. Mobile apps are definitely capable of having security bugs, and should be subjected to security reviews including penetration testing.

  • Scott Helme has occasionally reported randomly finding security issues because he runs a MITM attack against his phone just in regular use and flags apps that don't use secure connections, etc. There's an interesting thread that covers a little of this: twitter.com/scott_helme/status/1013446789712809984
    – nbering
    Commented Sep 16, 2018 at 22:41

As well as the penetration testing mentioned above you could have a third party perform a secure code review or have both performed by the same organization. If you have any static analysis tools you could supply the results as well as a list of vulnerabilities the tool checks for.

In my role I routinely take applications apart and find code that can be taken advantage of in given circumstances due to design decisions.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .