There’s no easier way to smear your name as an app company than by failing to protect your users and ensure fair play. To avoid that, include mobile app security checklists in your development process.

Take the game Pokémon Go, for example. Hackers installed the app, cracked their phones and got to the game’s code. Furthermore, they built a specific library and injected it into the app to manipulate GPS data. As a result, the hackers could travel around the game world without actually going anywhere, which made those playing fairly quite upset.

Getting to a phone’s root is known as Jailbreaking or Rooting, and this is a widely spread malicious practice. Once you have access to the root, you can change how the phone or app works, which the hackers used to play with GPS data in Pokémon Go. Unfortunately, Niantic has never been able to crack down on GPS spoofing.

Contents

    1. 10 Common Mobile App Security Mistakes
    2. Native vs Cross-Platform Apps: What’s More Secure?
    3. React Native Security Checklist

The good news is, you can prevent the most malignant practices that end up in dramatic losses. Since 2013, Rubyroid Labs has been building apps taking those practices into account. We’ve put together two mobile security checklists for you, expanding on common mistakes across platforms and best practices in React Native development.

Let’s dive right in.

10 Common Mobile App Security Mistakes

Web developers know the Open Web Application Security Project (OWASP). They check with the resource for the latest in web security, but it’s not limited to that. OWASP also provides advice on protecting mobile apps. Here are the ten common mobile app security mistakes to check for:

Ignoring platform-specific security guidelines

Every framework has its specifics when it comes to security. And every framework has manuals, including best practices, to factor in those specifics as you develop an app. The manuals for popular frameworks like React Native are frequently updated by their communities. So, there’s no better place to start securing your app.

Oversimplifying user authentication

You might be tempted to simplify authentication to attract more users in your app’s early days. But that also makes the hackers’ job easier. There are plenty of ways to steal logins and passwords, and if those are the only credentials required, you have a problem.

Now, you can’t prevent credential theft, but you can enforce two-step verification, so the login and password aren’t enough to gain access. In this case, the user would have to get a one-time code via SMS to prove they’re legit when trying to enter. Biometric logins and swipe patterns can also help protect users while keeping the experience smooth and simple.

Take this beyond the login screen and require verification at every risky step (e.g.: payment).

Not considering unsecured connections

People may use your app while connected to a public hotspot or unprotected mobile network. And although you can’t ensure no one can eavesdrop or intercept sensitive information, you can send the user a notification about the potential threat. Include those notifications in your mobile app security testing checklist

Short-shrifting encryption

There’s no point encrypting sensitive data in a way that disregards proven cryptography practices. Black-hat developers easily decrypt sloppy algorithms.

Leaving loopholes to high-level rights

Your app has high-level functionality reserved for admins and superusers. And you need to protect access to that functionality at all costs. You may decide to avoid using some complex authentication techniques for regular users to streamline their experience, but you mustn’t compromise high-level rights.

Flawed client code

Hackers can use buffer overflows, memory leaks and other client code issues to make your app do atypical things, like sending data to unauthorized parties. Mobile app security audit can help weed out code issues threatening security.

Neglecting anti-tampering measures

Black-hat programmers can change the app’s behavior by attacking the compiled app or a running process. To prevent that, you need to include anti-tampering measures in your mobile app development security checklist.

Failing to obfuscate the source code

If your code allows third parties to track it all the way back to the source code, you risk falling prey to reverse engineering. Reverse engineering is hackers decrypting the application’s binary and recreating the source code by using automated tools. To prevent that, you need to make code difficult to understand, or obfuscate it.

Leaving pieces of functional code in the front-end code

Developers often leave pieces of code related to what goes on behind the scenes of the app (e.g. staging environments) in its front end. Hackers can use these pieces to discover loopholes at the back end. Therefore, you should always clean the exposed part of your app, removing anything that doesn’t belong there.

Native vs Cross-Platform Apps: What’s More Secure?

There’s a common belief that apps built using OS-native technology are more secure than cross-platform apps. But evidence comparing native vs cross-platform apps doesn’t back up this belief.

Facebook, Instagram, Bloomberg, Coinbase and many other popular apps run on React Native, a powerful cross-platform framework. They certainly wouldn’t if the framework was unreliable.

At the end of the day, mobile security boils down to business logic, data storage and human error.

React Native Security Checklist

As we’ve already mentioned, the essential thing to do to secure your app is follow the guidelines of the platform you’re building on.

At Rubyroid Labs, we develop apps using React Native, a framework that comes with the best practices to ensure security. Check with them as you build your app or include them in your vetting process as you hire a React Native developer. Here’s the essential React Native security checklist presented as dos and don’ts.

Don’ts:

Don’t keep sensitive API keys in your front-end code

This precaution applies to any other framework. As a React Native developer, you shouldn’t confuse tools like react-native-dotenv and react-native-config with server-side environment variables which often contain secrets and API keys.

Don’t store the JSON Web Token (JWT) and secrets in Async Storage

React Native Async Storage is to mobile development as Local Storage is to the web. It’s also a file on a file system, which means hackers can get through to it. You can safely store nonsensitive data in Async Storage, but not the token or secrets.

Don’t send sensitive information in deep links

Like websites, apps have pages and URL addresses like app://pages/page1. And you register those URLs as a scheme using Xcode (iOS) or adding an intent (Android). But hackers can build an app that will provide access to the data in your links. So, never send tokens or secrets in deep links.

Dos:

Build an orchestration layer between your app and the resource you want the app to access
An orchestration layer like that is the perfect place to store an API key or a secret.

Use Keychain Services for iOS app security

What’s vulnerable in Async Storage (e.g. certificates, tokens and passwords) will reside safely in encrypted databases called keychains.

Use Encrypted Shared Preferences for Android app security

This service allows you to wrap the Android Shared Preferences class and automatically encrypt keys and values.

Use the Android Keystore system

You need to store cryptographic keys safely. And the best way to do so is by containering them, making them difficult to extract from the device. Android Keystore allows you to do exactly that.

Use the Proof of Key Code Exchange (PKCE)

PKCE is an extension to the OAuth 2 spec which provides an additional layer of security. It verifies that both the token exchange and the authentication originate from the same source.

Use SSL encryption with your APIs

Having an SSL certificate is essential to protect your app’s server communications by encrypting requests.

Use SSL pinning on the client side

Even with an SSL certificate, your app remains vulnerable to threats like the man-in-the-middle attack. The user phone checks the certificate using the pre-installed Certificate Authority. And hackers can install their own Certificate Authority on the phone to make it trust certain certificates made by them.

With React Native SSL pinning, you limit trusted certificates to a specific list. As a result, the app can’t use any others to check with SSL certificates.

Ready to Use the Mobile App Security Checklists?

Common mistakes in app development is where you start making a comprehensive mobile app security checklist. Once you know them, you will start to understand what hackers do. And by understanding that, you’ll be able to protect your users as you develop your app.

Cross-platforms apps are in general as secure as natively built ones. However, you should always check with the guidelines specific to the platform you use developing your app. And if you outsource the job, make sure they are familiar with those guidelines.

At Rubyroid Labs, we’ve built more than 50 mobile apps and we’ve not heard of a single one being hacked. And we can develop one for you — just request a free quote.

How useful was this post?

Click on a star to rate it!

Average rating 5 / 5. Vote count: 10

No votes so far! Be the first to rate this post.

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?


Author

VP of Engineering at Rubyroid Labs

Write A Comment