Contact FutureLearn for Support
Skip main navigation
We use cookies to give you a better experience, if that’s ok you can close this message and carry on browsing. For more info read our cookies policy.
We use cookies to give you a better experience. Carry on browsing if you're happy with this, or read our cookies policy for more information.

Data storage options

In this section, we introduce you to data storage options and to methods of securing stored data. In two exercises, you will be encouraged to identify potential vulnerabilities using BuggyTheApp

Let’s assume now that we have thought carefully about whether we really do need to store a particular piece of data and we have decide that we do, then what are our options for storing the data, and what are the security implications for each option?

There are 3 options for storing data:

  1. In memory.

  2. On disk (more specifically, some kind of non-volatile local storage, not necessarily a hard drive in the traditional sense).

  3. On a remote server (perhaps some kind of cloud service).

In memory storage

Storing data in memory provides only temporary storage of the data, as the data is lost when the app is closed, or the device is switched off. Securing data in memory is the responsibility of the Linux kernel, as it is the kernel that ensures one process can not access the memory of another process. However, the kernel can access all memory, so there is theoretically a security vulnerability there, but as an app developer we can do little about this.

Notes for Nerds: there are one or two tricks that an app developer can use to improve the security of data in memory. For example, the Java class PasswordAuthentication defines objects that hold two pieces of information: a username, and the corresponding password. The username is stored as a String object, but the password is stored as a char array. The reason is that String objects (the preferred way to handle strings in Java) are immutable, whereas char arrays are not. Thus when a PasswordAuthentication object is no longer needed the user can explicitly overwrite the password, whereas the username has to wait for the garbage collector to reclaim the memory and then reuse it before the value stored is finally erased. Leaving the password lying around in memory would potentially be a security risk if an attacker is able to examine your app’s memory.

On disk and remote server storage

On disk and remote server storage are the topics we will cover this week.

From the perspective of an app developer, securing remote server storage is mostly about securing the network connection, as securing the data on the server itself is not our job. We will cover securing network connections later.

Storing data on disk can be done essentially in one of two ways:

  1. Explicitly: through the direct creation of files.

  2. Implicitly: through the use of storage mechanisms provided by the Android platform, where the physical storage of the data on disk (as files) is performed by Android itself. The two main examples of such mechanisms are SharedPreferences or SQLite databases.

Share this article:

This article is from the free online course:

Secure Android App Development

University of Southampton