8 mobile app security threats

We store a lot of information on our devices. When this information is compromised, serious damage can be done to devices… and users. 

Encrypting your data is a great step, but it’s not foolproof; anything that can be encrypted can also be decrypted.

From Facebook to your bank account, security and data privacy are extremely important. And delivering a perfectly working, highly secure app is vital to user retention. That’s why it’s essential for QA to test sensitive data storage and how your app behaves under various device permission schemes.

Mobile app security testing

Mobile app data breaches are an increasingly popular target among cybercriminals — costing an average of $3.86 million. 

Mobile application security testing can help ensure there aren’t any software loopholes that could cause data loss. These tests are meant to attack the app from a hacker’s point of view to identify possible threats and vulnerabilities.

Eight common security threats for mobile applications

1. Security breaches that allow malware to be installed

Malware is malicious software embedded in a downloadable file that installs itself if it finds a particular breach.

Just last year, Monokle — surveillanceware by the Russian company Special Technology Centre (STC) — was noted as one of the most dangerous Android malware in recent history. If STC sounds familiar, that may be because it provided material support to disrupt the 2016 US presidential election.

A set of custom ‘surveillanceware’ tools, Monokle “has been used in highly targeted attacks at least since March 2016, it supports a wide range of spying functionalities, and implements advanced data exfiltration techniques.”

2. Unnecessary or insecure data storage

Sometimes developers depend upon client storage for data, but this isn’t impenetrable to security breaches. The best way to secure data storage across platforms is to build an additional layer of encryption over the base level encryption provided by the OS and taking advantage of specialized device hardware like the Secure Enclave on iOS.

3. Malicious third-party code

While developers don’t normally write 3rd party code, there are various other ways this malicious code is being integrated:

• Writing code that is unnecessary: Code that does not get used can become a security problem if attackers know how to trigger it.
• Integrating 3rd party libraries: Third-party libraries are good to have but it comes with lurking dangers and vulnerabilities. Ensure that the third-party your mobile app integrates with is ethical and trustworthy and up to date.

4. Authentication procedures

Gone are the days where login information is the only point of contact that needs encryption. The full connection has to use strong end-to-end encryption.

5. App permissions

Though app permissions are supposed to act as a practical barrier between app makers and specific parts of your phone’s data, that’s not always the case. App stores encourage developers to explain permissions but these can be short or purposefully vague.

Nefarious permission violations include:

• Access to location: Once location access is granted, app makers are able to pull in bearing and altitude information meaning they know “roughly which floor of a highrise you live on”.
• All access pass: Widely popular game Pokemon Go, required full access to user Google account information meaning it could see AND modify nearly all information in your Google Account.

Even if you don’t have an app — or even an account in some cases — companies can still gain a general sense of who you are. As is the case of Facebook.

The social media platform creates shadow profiles — a term for non-user data collection in which it gathers information on non-users through uploaded contact lists, photos, or other sources”.

6. Insecure transport layer protection

Transport layer refers to the route through which the data is sent or received between client and server. Use end-to-end encryption to keep prying eyes from reading content. WhatsApp’s messaging and communication encryption is a good example.

7. Weak or removed server-side controls

Communication sometimes occurs through a server which is oftentimes a target of hackers. These “man-in-the-middle” attacks happen when security certificate controls are bypassed. One way this happens is if mobile app developers disable security certificate verification when testing specific features and forget to turn that security back on. Always run a controlled man-in-the-middle scenario to find potential dangers.

8. Client side injection

Working similarly to certain server-side security risks, client-side injection in mobile applications happens when software inappropriately treats inputted data as code. The key difference is that the code is submitted to the client instead of the server. The best way to prevent application injection vulnerabilities is to identify sources of input and ensure that user and application supplied data is subject to input validation.

Strategy for security testing

As a QA, know the following items in order to craft a solid testing strategy:

Types of penetration tests

Penetration tests — or a computer-based security assessment where QA attempts to hack into the system. There are two types of penetration tests:

• White Box testing: White Box testing — also known as Clear Box testing, Open Box testing, Structural testing, Transparent Box testing, Code-Based testing, and Glass Box testing — is where code is visible to developers and focuses on testing the software’s internal structure, design, and coding. 
  
• Black Box testing: Black Box testing — also referred to as Specification-based or Behavioral Testing, is an input / output-driven testing technique (based solely on software requirements and specifications) in which the tester tests without looking at the internal code structure, implementation details, nor knowledge of internal paths of the software (essentially focusing on what the software does instead of how it does it). 
  

Nature of your app

Depending on the nature of your app, decide how much security testing is required. While all personal user data is important, different apps require more or less security requirements. For example, if your app deals with money transactions, then you need to address those additional security aspects as well.

Testing timelines

Security testing should start on day one… it should be built in from the very beginning. In order to prioritize and maximize your testing, consider static code reviews and encourage constructive criticism.

Hidden app functions and code

Vulnerabilities can be found everywhere. Especially in hidden parameter code that — left without some protection — become vulnerabilities themselves. 

For example, SQL shortcuts for text boxes, drop-down menus, and other UI precoded elements are notoriously susceptible to attacks.

Are security threats different for Android and iOS?

In short: yes. 

Apple maintains very strict rules for application distribution in the iTunes store thus lowering the risk of malware or malicious apps. This means iOS is less susceptible to security threats compared to Android. As such, QAs must consider security feature differences between Android and iOS.

With thousands of validated testers in nearly 100 countries, Testlio offers a massive pool of the best QA testers in the business. Get in touch for a free demo.