We’ve all heard of mobile SDKs. These off-the-shelf mobile services, which app developers integrate in your app for many purposes: advertising and payment, analytics and social, and many many more. No doubt these SDKs are a great help in your development process. They often offer unique functionalities, simplify your coding and save you precious time and money. It’s not a surprise that the 1,000 most popular apps contain on average 15 SDKs.

But SDKs are not really your code. It is actually someone else’s code interleaved with your own, yet you are liable for it. You are responsible for it in the eyes of Apple, Google and most importantly – your users. Why is this a problem? Well, in this post, I’ll explain two major domains of risk when using SDKs, and spice it up with a few real-life stories.

1. Security, Privacy and Compliance

The dark side of app permissions

Once hosted in the application, the SDK is part of the application code and can access any user data that the application was granted access to. If the app can access users’ location, contacts or private files, so does each and every SDK in the app.

We often see Android SDKs containing code similar to this:

if (context.checkCallingOrSelfPermission(“android.permission.ACCESS_FINE_LOCATION”)
              == PackageManager.PERMISSION_GRANTED) {
     Location userLocalLocation =
                localLocationManager.getLastKnownLocation("gps");
}

The SDK simply checks if the app was granted a permission to access the user’s location, and if so it takes advantage of it and accesses the GPS as well. We can often see that SDKs send this information to external servers.

Let this be a cautionary tale to all you folks integrating SDKs: what the SDK doesn’t tell you may hurt you. In the case above, the SDK could simply not declare using the Location permission and only exploit it should your app have it. All might be done behind the scenes, and worse – behind your back and on your watch.

Continue Reading