7 Security Pitfalls in your App

Currently, there are approximately 4.5 million plus apps available on the Apple app store and Google play store (Buildfire.com). Of that:

• 49% of apps harbour at least one high-risk flaw

• 17% of apps reveal sensitive user data

• 29% of apps send unencrypted traffic


As a hacker, when I scope a site I’m looking for shortcuts, loopholes and implementation errors. I'm looking to pull apart the target line by line and find ways to break it. I hack to help the people who do not understand how to effectively use technology. Hackers like me are known as white hackers. We participate in programs that let us identify vulnerabilities so they can then be fixed, making sure the average user doesn't have any serious issues.

So who are we trying to stop? Adversaries...

An adversary is not always another 'hacker' trying to steal your bank account details. Adversaries could be anyone trying to gather your information such as marketing teams and other businesses that want information about you as it helps to inform them on what you want and how to get you to buy it.

When you build an app for the first time, there is a lot you’re having to try and get done. You're trying to catch up on the development process, organise design and developers, get the marketing set up and you’re doing all of it on the smell of an oil rag. Starting your app is a race to the bottom (the bottom of your account balance). You are racing time and in your first few versions, when you are moving fast, things get missed and overlooked. This is why many people look to digital agencies to help them build quality apps in short time frames.

It is common place to build web apps or hybrid apps (See What Type of App is Right for your Idea?) due to them being compatible with multiple platforms. So for this article we will focus on some of the pitfalls that may exist in these types of apps that should be tended to ASAP!

1. Injection Attacks - Poor Sanitation Practices

Injection attacks refer to inputs that can produce an unintended result. These types of attacks usually occur when code is put into an input field and it causes something to happen. There are a number of types of injection attacks such as:

• HTML Injection - where an input field does not correctly handle an input and allows HTML code to be entered and rendered on the page.

• XSS or Cross Site Scripting - where script tags are used to run javascript that is input into an input field in your application, similar to HTML Injection.

• SQL Injection - where a malicious SQL statement or statements are entered into an input field. Actions like accessing a list of usernames and passwords or deleting the database is possible with SQL injection in some cases.

Sanitisation of inputs should be common practice in your application. Failure to do so opens your application up to multiple exploits, all of which you are liable for. During the testing of your application or a new feature, it is good practice to test entering unexpected values and even code into the input fields to see what happens. For examples of these inputs just google “<Attack Name> examples list” and you can get lists to test your application. 

2. Information leakage

Application Cache information leakage can occur through the application code or third party frameworks. Mobile devices can pose a challenge due to many people not locking their phones with a password. It doesn't matter if you don't care about people seeing your information, this may be a concern for others. Speak to your developer about creating a threat model at each level of the application - OS, framework and platform. This model should be used to check and verify the way data is handled during URL caching, keyboard pressing caching, copy and paste caching, app backgrounding, browser cookies, HTML data storage and analytic data that is sent to the server or another app. This is particularly critical if you are handling personal and sensitive information within the application.

3. Insufficient Authorisation/Authentication

If your application contains any information that is even remotely sensitive, it is safe to assume that your users will be expecting the option of 2 Factor Authentication (2FA). Thankfully, this is becoming best practice. 2FA works on the premise that there are 3 ways to verify to the system that you are who you say you are:

  1. Something you know - like a password.
  2. Something you have - Mobile phone for a text message or push notification code.
  3. Something you are - Biological attribute like a fingerprint or retina scan.

2 Factor Authentication merely refers to accessing an account using two of these. Key vulnerabilities often lay in the implementation of 2FA. Ensure you use a proven framework scheme that focuses on policy-based configuration files over hard coded authentication where possible. The most common and minimum standard is to send a verification email but other options like integrating Google Authenticator or sending a text message to a phone number connected to your account are other popular ways of 2FA being used.

4. PIN Codes and Passwords

Force your users to create strong passwords and, where possible, limit the use of PIN codes. The old 4 digit pin on its own has 10 ,000 possible combinations. UK security company MDSec used a device that could use brute force to unlock an iPhone in under 111 hours, averaging around 55 hours. 

A study carried out by Data Genetics (See original HERE) looked at 3.4 million pin codes and found that:

• 10% of codes were '1234'.

• '1234', '1111' and '0000' made up 20% of codes.

• The top 20 codes accounted for almost 27% (26.83%) of all codes.

• 2580 was the 22nd most popular code.

Still feel your PIN code is safe?

Why share this with you? Because if you are trying to build a secure platform, pin codes should not even be a consideration. Yes they provide some convenience but even Apple gives you 10 attempts before going into lockout or a data wipe can be accessed. A hack isn’t always about collecting data, sometimes the erasing of data is just as good a result.

Good password practice is creating a password that is a mixture of numbers, special characters, upper and lower case letters and is over 12 characters long (16 is good). Let this be the minimum standard you hold your users to. The result of not using secure passwords as standard leaves your application open to user emulation.

• Brute force calculator: https://tmedweb.tulane.edu/content_open/bfcalc.php?uc=&lc=&nu=4&sc=&ran=&rans=&dict= 

It is currently recommended that 15 character passwords with a random combination of upper case letters, lower case letters, numbers and special characters are used to secure your account.

5. Certificate Validation

SSL/TLS is the bare minimum for any software company in 2020 and beyond. It’s cheap and it gives your application legitimacy. A DV SSL (Domain Validated) is enough to give you basic protection. Without SSL, your website can not be validated. In other words, your user won’t know if you're legitbusiness.com or evil.com with a legitbusiness.com mask on. There are a number of different SSL certificates available and it will depend on your application as to which will best suit you. See this link for more on SSL: (https://www.globalsign.com/en-au/ssl-information-center/types-of-ssl-certificate#:~:text=There are three types of,needed to obtain the certificate.)

6. Binary Protection - Code Obfuscation

This is specifically an Android issue. It is possible to reverse engineer an Android application. However, code obfuscation will help to prevent this from happening. If you fail to do this, it’s like giving the user manual and key to a carjacker. There are tools like ProGuard (a Google tool), which shrink and optimise the source code. It obfuscates by removing any unused code and renaming classes, fields and methods with obscure names which produces the .apk file your developer will often send you to test an Android build. A .apk file is smaller and more difficult to reverse engineer.

7. Session expiry

This is where the logout function is not properly implemented and an attack can reuse old session credentials or session IDs. Ensuring your application sufficiently expires a session is vital to the safety of users. When not implemented correctly, an adversary can take the identifier that has failed to be invalidated by the server and use it to impersonate the user, performing actions as that user which may not always be in the users interest.

Applications should invalidate sessions after a predefined idle time, as well as providing logout functionality which invalidates their own session. Session IDs should be set to have a lifespan that is as short as possible to prevent windows of opportunity for an attack. Logout should be prominent and explicitly state the invalidation of the session.


Pay for Testing! Penetration and QA Testing is where a team hacks and tests your application, putting it through its paces with edge cases, false responses and more. They locate any potential issues and make you aware of them so they can be patched before a malicious adversary can take advantage of the vulnerability. It may initially seem like a waste of money, but you wouldn't build a car in your garage and then just take it for a trip around Australia without going and getting it checked and tested by a mechanic first. So why let your application into the wild without having it checked and tested? A basic security analysis is often only a few hundred dollars and could be the very thing that saves your app from an attack.