In this document
- Storing Data
- Using Permissions
- Using Networking
- Performing Input Validation
- Handling User Data
- Using WebView
- Using Cryptography
- Using Interprocess Communication
- Dynamically Loading Code
- Security in a Virtual Machine
- Security in Native Code
Android has security features built into the operating system that significantly reduce the frequency and impact of application security issues. The system is designed so you can typically build your apps with default system and file permissions and avoid difficult decisions about security.
Some of the core security features that help you build secure apps include:
- The Android Application Sandbox, which isolates your app data and code execution from other apps.
- An application framework with robust implementations of common security functionality such as cryptography, permissions, and secure IPC.
- Technologies like ASLR, NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD calloc, and Linux mmap_min_addr to mitigate risks associated with common memory management errors.
- An encrypted filesystem that can be enabled to protect data on lost or stolen devices.
- User-granted permissions to restrict access to system features and user data.
- Application-defined permissions to control application data on a per-app basis.
Nevertheless, it is important that you be familiar with the Android security best practices in this document. Following these practices as general coding habits will reduce the likelihood of inadvertently introducing security issues that adversely affect your users.
The most common security concern for an application on Android is whether the data that you save on the device is accessible to other apps. There are three fundamental ways to save data on the device:
Using internal storage
By default, files that you create on internal storage are accessible only to your app. This protection is implemented by Android and is sufficient for most applications.
You should generally avoid using the
MODE_WORLD_READABLE modes for
IPC files because they do not provide
the ability to limit data access to particular applications, nor do they
provide any control on data format. If you want to share your data with other
app processes, you might instead consider using a
content provider, which
offers read and write permissions to other apps and can make
dynamic permission grants on a case-by-case basis.
To provide additional protection for sensitive data, you might
choose to encrypt local files using a key that is not directly accessible to the
application. For example, a key can be placed in a
and protected with a user password that is not stored on the device. While this
does not protect data from a root compromise that can monitor the user
inputting the password, it can provide protection for a lost device without file system
Using external storage
Files created on external storage, such as SD Cards, are globally readable and writable. Because external storage can be removed by the user and also modified by any application, you should not store sensitive information using external storage.
As with data from any untrusted source, you should perform input validation when handling data from external storage. We strongly recommend that you not store executables or class files on external storage prior to dynamic loading. If your app does retrieve executable files from external storage, the files should be signed and cryptographically verified prior to dynamic loading.
Using content providers
offer a structured storage mechanism that can be limited
to your own application or exported to allow access by other applications.
If you do not intend to provide other
applications with access to your
ContentProvider, mark them as
android:exported=false in the application manifest. Otherwise, set the
"true" to allow other apps to access the stored data.
When creating a
that will be exported for use by other applications, you can specify a single
for reading and writing, or distinct permissions for reading and writing
within the manifest. We recommend that you limit your permissions to those
required to accomplish the task at hand. Keep in mind that it’s usually
easier to add permissions later to expose new functionality than it is to take
them away and break existing users.
If you are using a content provider
for sharing data between only your own apps, it is preferable to use the
android:protectionLevel attribute set to
Signature permissions do not require user confirmation,
so they provide a better user experience and more controlled access to the
content provider data when the apps accessing the data are
the same key.
Content providers can also provide more granular access by declaring the
android:grantUriPermissions attribute and using the
FLAG_GRANT_WRITE_URI_PERMISSION flags in the
that activates the component. The scope of these permissions can be further
limited by the
When accessing a content provider, use parameterized query methods such as
delete() to avoid
potential SQL injection from untrusted sources. Note that using parameterized methods is not
sufficient if the
selection argument is built by concatenating user data
prior to submitting it to the method.
Do not have a false sense of security about the write permission. Consider
that the write permission allows SQL statements which make it possible for some
data to be confirmed using creative
WHERE clauses and parsing the
results. For example, an attacker might probe for presence of a specific phone
number in a call-log by modifying a row only if that phone number already
exists. If the content provider data has predictable structure, the write
permission may be equivalent to providing both reading and writing.
Because Android sandboxes applications from each other, applications must explicitly share resources and data. They do this by declaring the permissions they need for additional capabilities not provided by the basic sandbox, including access to device features such as the camera.
We recommend minimizing the number of permissions that your app requests. Not having access to sensitive permissions reduces the risk of inadvertently misusing those permissions, can improve user adoption, and makes your app less vulnerable for attackers. Generally, if a permission is not required for your app to function, do not request it.
If it's possible to design your application in a way that does not require any permissions, that is preferable. For example, rather than requesting access to device information to create a unique identifier, create a GUID for your application (see the section about Handling User Data). Or, rather than using external storage (which requires permission), store data on the internal storage.
In addition to requesting permissions, your application can use the
to protect IPC that is security sensitive and will be exposed to other
applications, such as a
In general, we recommend using access controls
other than user confirmed permissions where possible because permissions can
be confusing for users. For example, consider using the signature
protection level on permissions for IPC communication between applications
provided by a single developer.
Do not leak permission-protected data. This occurs when your app exposes data over IPC that is available only because your app has permission to access that data. The clients of your app's IPC interface may not have that same data-access permission. More details on the frequency and potential effects of this issue appear in this research paper, published at USENIX.
Generally, you should strive to define as few permissions as possible while satisfying your security requirements. Creating a new permission is relatively uncommon for most applications, because the system-defined permissions cover many situations. Where appropriate, perform access checks using existing permissions.
If you must create a new permission, consider whether you can accomplish your task with a "signature" protection level. Signature permissions are transparent to the user and only allow access by applications signed by the same developer as application performing the permission check.
If you create a permission with the "dangerous" protection level, there are a number of complexities that you need to consider:
- The permission must have a string that concisely expresses to a user the security decision they will be required to make.
- The permission string must be localized to many different languages.
- Users may choose not to install an application because a permission is confusing or perceived as risky.
- Applications may request the permission when the creator of the permission has not been installed.
Each of these poses a significant non-technical challenge for you as the developer while also confusing your users, which is why we discourage the use of the "dangerous" permission level.
Network transactions are inherently risky for security, because it involves transmitting data that is potentially private to the user. People are increasingly aware of the privacy concerns of a mobile device, especially when the device performs network transactions, so it's very important that your app implement all best practices toward keeping the user's data secure at all times.
Using IP Networking
Networking on Android is not significantly different from other Linux
environments. The key consideration is making sure that appropriate protocols
are used for sensitive data, such as
secure web traffic. We prefer use of HTTPS over HTTP anywhere that HTTPS is
supported on the server, because mobile devices frequently connect on networks
that are not secured, such as public Wi-Fi hotspots.
Authenticated, encrypted socket-level communication can be easily
implemented using the
class. Given the frequency with which Android devices connect to unsecured
wireless networks using Wi-Fi, the use of secure networking is strongly
encouraged for all applications that communicate over the network.
We have seen some applications use localhost network ports for
handling sensitive IPC. We discourage this approach since these interfaces are
accessible by other applications on the device. Instead, you should use an Android IPC
mechanism where authentication is possible such as with a
worse than using loopback is to bind to INADDR_ANY since then your application
may receive requests from anywhere.)
Also, one common issue that warrants repeating is to make sure that you do
not trust data downloaded from HTTP or other insecure protocols. This includes
validation of input in
any responses to intents issued against HTTP.
Using Telephony Networking
The SMS protocol was primarily designed for user-to-user communication and is not well-suited for apps that want to transfer data. Due to the limitations of SMS, we strongly recommend the use of Google Cloud Messaging (GCM) and IP networking for sending data messages from a web server to your app on a user device.
Beware that SMS is neither encrypted nor strongly
authenticated on either the network or the device. In particular, any SMS receiver
should expect that a malicious user may have sent the SMS to your application—Do
not rely on unauthenticated SMS data to perform sensitive commands.
Also, you should be aware that SMS may be subject to spoofing and/or
interception on the network. On the Android-powered device itself, SMS
messages are transmitted as broadcast intents, so they may be read or captured
by other applications that have the
Performing Input Validation
Insufficient input validation is one of the most common security problems affecting applications, regardless of what platform they run on. Android does have platform-level countermeasures that reduce the exposure of applications to input validation issues and you should use those features where possible. Also note that selection of type-safe languages tends to reduce the likelihood of input validation issues.
If you are using native code, then any data read from files, received over the network, or received from an IPC has the potential to introduce a security issue. The most common problems are buffer overflows, use after free, and off-by-one errors. Android provides a number of technologies like ASLR and DEP that reduce the exploitability of these errors, but they do not solve the underlying problem. You can prevent these vulneratbilities by careful handling pointers and managing buffers.
If you are using data within queries that are submitted to an SQL database or a content provider, SQL injection may be an issue. The best defense is to use parameterized queries, as is discussed in the above section about content providers. Limiting permissions to read-only or write-only can also reduce the potential for harm related to SQL injection.
If you cannot use the security features above, we strongly recommend the use of well-structured data formats and verifying that the data conforms to the expected format. While blacklisting of characters or character-replacement can be an effective strategy, these techniques are error-prone in practice and should be avoided when possible.
Handling User Data
In general, the best approach for user data security is to minimize the use of APIs that access sensitive or personal user data. If you have access to user data and can avoid storing or transmitting the information, do not store or transmit the data. Finally, consider if there is a way that your application logic can be implemented using a hash or non-reversible form of the data. For example, your application might use the hash of an an email address as a primary key, to avoid transmitting or storing the email address. This reduces the chances of inadvertently exposing data, and it also reduces the chance of attackers attempting to exploit your application.
You should also consider whether your application might be inadvertently exposing personal information to other parties such as third-party components for advertising or third-party services used by your application. If you don't know why a component or service requires a personal information, don’t provide it. In general, reducing the access to personal information by your application will reduce the potential for problems in this area.
If access to sensitive data is required, evaluate whether that information must be transmitted to a server, or whether the operation can be performed on the client. Consider running any code using sensitive data on the client to avoid transmitting user data.
Also, make sure that you do not inadvertently expose user data to other application on the device through overly permissive IPC, world writable files, or network sockets. This is a special case of leaking permission-protected data, discussed in the Requesting Permissions section.
If a GUID is required, create a large, unique number and store it. Do not use phone identifiers such as the phone number or IMEI which may be associated with personal information. This topic is discussed in more detail in the Android Developer Blog.
Be careful when writing to on-device logs.
In Android, logs are a shared resource, and are available
to an application with the
Even though the phone log data
is temporary and erased on reboot, inappropriate logging of user information
could inadvertently leak user data to other applications.
improper use can introduce common web security issues such as cross-site-scripting
the scope of these potential issues by limiting the capability of
the minimum functionality required by your application.
Some sample code uses this method, which you might repurpose in production
application, so remove that method call if it's not required. By default,
normally reserved for Android applications. If you use it, expose
web pages from which all input is trustworthy. If untrusted input is allowed,
If your application accesses sensitive data with a
WebView, you may want to use the
clearCache() method to delete any files stored
no-cache can also be used to indicate that an application should
not cache particular content.
Devices running platforms older than Android 4.4 (API level 19)
use a version of
webkit that has a number of security issues.
As a workaround, if your app is running on these devices, it
should confirm that
WebView objects display only trusted
content. You should also use the updatable security
Provider object to make sure your app isn’t exposed to
potential vulnerabilities in SSL, as described in Updating Your
Security Provider to Protect Against SSL Exploits. If your application must
render content from the open web, consider providing your own renderer so
you can keep it up to date with the latest security patches.
In general, we recommend minimizing the frequency of asking for user credentials—to make phishing attacks more conspicuous, and less likely to be successful. Instead use an authorization token and refresh it.
Where possible, username and password should not be stored on the device. Instead, perform initial authentication using the username and password supplied by the user, and then use a short-lived, service-specific authorization token.
Services that will be accessible to multiple applications should be accessed
AccountManager. If possible, use the
AccountManager class to invoke a cloud-based service and do not store
passwords on the device.
If credentials are to be used only by applications that you create, then you
can verify the application which accesses the
Alternatively, if only one application will use the credential, you might use a
KeyStore for storage.
In addition to providing data isolation, supporting full-filesystem encryption, and providing secure communications channels, Android provides a wide array of algorithms for protecting data using cryptography.
In general, try to use the highest level of pre-existing framework
implementation that can support your use case. If you need to securely
retrieve a file from a known location, a simple HTTPS URI may be adequate and
requires no knowledge of cryptography. If you need a secure
tunnel, consider using
SSLSocket, rather than writing your own protocol.
If you do find yourself needing to implement your own protocol, we strongly
recommend that you not implement your own cryptographic algorithms. Use
existing cryptographic algorithms such as those in the implementation of AES or
RSA provided in the
Use a secure random number generator,
to initialize any cryptographic keys,
Use of a key that is not generated with a secure random
number generator significantly weakens the strength of the algorithm, and may
allow offline attacks.
If you need to store a key for repeated use, use a mechanism like
provides a mechanism for long term storage and retrieval of cryptographic
Using Interprocess Communication
Some apps attempt to implement IPC using traditional Linux
techniques such as network sockets and shared files. We strongly encourage you to instead
use Android system functionality for IPC such as
Messenger with a
The Android IPC mechanisms allow you to verify the identity of
the application connecting to your IPC and set security policy for each IPC
Many of the security elements are shared across IPC mechanisms.
If your IPC mechanism is not intended for use by other applications, set the
android:exported attribute to
"false" in the component's manifest element,
such as for the
element. This is useful for applications that consist of multiple processes
within the same UID, or if you decide late in development that you do not
actually want to expose functionality as IPC but you don’t want to rewrite
If your IPC is intended to be accessible to other applications, you can
apply a security policy by using the
element. If IPC is between your own separate apps that are signed with the same key,
it is preferable to use
"signature" level permission in the
Intents are the preferred mechanism for asynchronous IPC in Android.
Depending on your application requirements, you might use
or an explicit intent to a specific application component.
Note that ordered broadcasts can be “consumed” by a recipient, so they may not be delivered to all applications. If you are sending an intent that must be delivered to a specific receiver, then you must use an explicit intent that declares the receiver by nameintent.
Senders of an intent can verify that the recipient has a permission specifying a non-Null permission with the method call. Only applications with that permission will receive the intent. If data within a broadcast intent may be sensitive, you should consider applying a permission to make sure that malicious applications cannot register to receive those messages without appropriate permissions. In those circumstances, you may also consider invoking the receiver directly, rather than raising a broadcast.
Note: Intent filters should not be considered a security feature—components can be invoked with explicit intents and may not have data that would conform to the intent filter. You should perform input validation within your intent receiver to confirm that it is properly formatted for the invoked receiver, service, or activity.
Service is often used to supply functionality for other applications to
use. Each service class must have a corresponding
declaration in its
By default, services are not exported and cannot be invoked by any other
application. However, if you add any intent filters to the service declaration, then it is exported
by default. It's best if you explicitly declare the
android:exported attribute to be sure it behaves as you'd like.
Services can also be protected using the
attribute. By doing so, other applications will need to declare
element in their own manifest to be
able to start, stop, or bind to the service.
A service can protect individual IPC calls into it with permissions, by
checkCallingPermission() before executing
the implementation of that call. We generally recommend using the
declarative permissions in the manifest, since those are less prone to
Using binder and messenger interfaces
We strongly encourage designing interfaces in a manner that does not require
interface specific permission checks.
Messenger objects are not declared within the
application manifest, and therefore you cannot apply declarative permissions
directly to them. They generally inherit permissions declared in the
application manifest for the
Activity within which they are
implemented. If you are creating an interface that requires authentication
and/or access controls, those controls must be
explicitly added as code in the
If providing an interface that does require access controls, use
to verify whether the
caller has a required permission. This is especially important
before accessing a service on behalf of the caller, as the identify of your
application is passed to other interfaces. If invoking an interface provided
invocation may fail if you do not have permission to access the given service.
If calling an interface provided locally by your own application, it may be
useful to use the
to satisfy internal security checks.
For more information about performing IPC with a service, see Bound Services.
Using broadcast receivers
By default, receivers are exported and can be invoked by any other
application. If your
is intended for use by other applications, you
may want to apply security permissions to receivers using the
<receiver> element within the application manifest. This will
prevent applications without appropriate permissions from sending an intent to
Dynamically Loading Code
We strongly discourage loading code from outside of your application APK. Doing so significantly increases the likelihood of application compromise due to code injection or code tampering. It also adds complexity around version management and application testing. Finally, it can make it impossible to verify the behavior of an application, so it may be prohibited in some environments.
If your application does dynamically load code, the most important thing to keep in mind about dynamically loaded code is that it runs with the same security permissions as the application APK. The user made a decision to install your application based on your identity, and they are expecting that you provide any code run within the application, including code that is dynamically loaded.
The major security risk associated with dynamically loading code is that the
code needs to come from a verifiable source. If the modules are included
directly within your APK, then they cannot be modified by other applications.
This is true whether the code is a native library or a class being loaded using
DexClassLoader. We have seen many instances of applications
attempting to load code from insecure locations, such as downloaded from the
network over unencrypted protocols or from world writable locations such as
external storage. These locations could allow someone on the network to modify
the content in transit, or another application on a users device to modify the
content on the device, respectively.
Security in a Virtual Machine
Dalvik is Android's runtime virtual machine (VM). Dalvik was built specifically for Android, but many of the concerns regarding secure code in other virtual machines also apply to Android. In general, you shouldn't concern yourself with security issues relating to the virtual machine. Your application runs in a secure sandbox environment, so other processes on the system cannnot access your code or private data.
If you're interested in diving deeper on the subject of virtual machine security, we recommend that you familiarize yourself with some existing literature on the subject. Two of the more popular resources are:
This document is focused on the areas which are Android specific or different from other VM environments. For developers experienced with VM programming in other environments, there are two broad issues that may be different about writing apps for Android:
- Some virtual machines, such as the JVM or .net runtime, act as a security boundary, isolating code from the underlying operating system capabilities. On Android, the Dalvik VM is not a security boundary—the application sandbox is implemented at the OS level, so Dalvik can interoperate with native code in the same application without any security constraints.
- Given the limited storage on mobile devices, it’s common for developers to want to build modular applications and use dynamic class loading. When doing this, consider both the source where you retrieve your application logic and where you store it locally. Do not use dynamic class loading from sources that are not verified, such as unsecured network sources or external storage, because that code might be modified to include malicious behavior.
Security in Native Code
In general, we encourage developers to use the Android SDK for application development, rather than using native code with the Android NDK. Applications built with native code are more complex, less portable, and more like to include common memory corruption errors such as buffer overflows.
Android is built using the Linux kernel and being familiar with Linux development security best practices is especially useful if you are going to use native code. Linux security practices are beyond the scope of this document, but one of the most popular resources is “Secure Programming for Linux and Unix HOWTO”, available at http://www.dwheeler.com/secure-programs.
An important difference between Android and most Linux environments is the Application Sandbox. On Android, all applications run in the Application Sandbox, including those written with native code. At the most basic level, a good way to think about it for developers familiar with Linux is to know that every application is given a unique UID with very limited permissions. This is discussed in more detail in the Android Security Overview and you should be familiar with application permissions even if you are using native code.