Secure Coding

Secure Coding Guidelines For Android Developer

Sharing is caring!


Android has built-in security features that significantly reduce the frequency and impact of application security issues. Developer should follow secure coding best practices for developing secure app.

These are following secure coding guidelines, android developer should follow:

Do not store sensitive information on external storage (SD card) in plain text

Android provides several options to save persistent application data, one of which is External Storage (/sdcard, /mnt/sdcard). “External storage” examples include a micro- or standard-sized SD card internal to the device.

According to Android Developer staorage option guidelines
“Caution: External storage can become unavailable if the user mounts the external storage on a computer or removes the media, and there’s no security enforced upon files you save to the external storage. All applications can read and write files placed on the external storage and the use can remove them”.

Developers should not store sensitive data to external storage devices unless encrypted first, because files stored externally have no guarantee of availability, integrity, and confidentiality. Developer can also save a File on Internal Storage.

Protect exported services with strong permissions

A Service is often used to supply functionality for other applications to use. Each service class must have a corresponding declaration in its manifest file.

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, 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 android:permission attribute. By doing so, other applications need to declare a corresponding element in their own manifest to be able to start, stop, or bind to the service.

Restrict access to sensitive activities

If app is setting an intent filter for an activity in the AndroidManifest.xml file means that the activity may be exported to other apps.If the activity is intended solely for the internal use of the app and an intent filter is declared then any other apps, including malware, can activate the activity for unintended use.

Developer should set android:exported=”false” for an activity tag in the AndroidManifest.xml file, the activity is restricted to only accept intents from within the same app or from an app with the same user ID.

Restrict the accessibility of an app’s sensitive content provider

The ContentProvider class provides a mechanism for managing and sharing data with other applications. When sharing a provider’s data with other apps, access control should be carefully implemented to prohibit unauthorized access to sensitive data.

There are three ways to limit access to the content provider public, private and restricted access.

Devloper can make this changes by specifying the android:exported to attribute in the AndroidManifest.xml file. This makes the content provider private so that other apps cannot access the data: .This attribute sould set as false.

Do not allow WebView to access sensitive local resource through file scheme

The WebView class displays web pages as part of an activity layout. The behavior of a WebView object can be customized using the WebSettings object, which can be obtained from WebView.getSettings().

Major security concerns for WebView are about the setJavaScriptEnabled(), setPluginState(), and setAllowFileAccess() methods.

Any URI received via an intent from outside a trust-boundary should be validated before rendering it with WebView. For example, the following code checks an received URI and uses it only when it is not a file: scheme URI.

String intentUrl = getIntent().getStringExtra(“url”);
String localUrl = “about:blank”;
if (!intentUrl.startsWith(“file:”)) {
loadUrl = intentUrl;

Do not broadcast sensitive information using an implicit intent

Android applications’ core components such as activities, services, and broadcast receivers are activated through messages, called intents. Applications can use broadcast to send messages to multiple applications.

By default, receivers are exported and can be invoked by any other application. If your BroadcastReceiver is intended for use by other applications, you may want to apply security permissions to receivers using the element within the application manifest file. This prevents applications without appropriate permissions from sending an intent to the BroadcastReceiver.

If the intent is only broadcast/received in the same application, LocalBroadcastManager can be used so that, by design, other apps cannot received the broadcast message, which reduces the risk of leaking sensitive information.

Instead of using Context.sendBroadcast(), use LocalBroadcastManager.sendBroadcast().

Do not log sensitive information

Android provides capabilities for an app to output logging information and obtain log output. Applications should make sure that they do not send sensitive information to log output. If the app includes a third party library, the developer should make sure that the library does not send sensitive information to log output. One common solution is for an application to declare and use a custom log class, so that log output is automatically turned on/off based on Debug/Release.

Do not release apps that are debuggable

Android allows the attribute android:debuggable to be set to true in the manifest, so that the app can be debugged. By default this attribute is disabled, i.e., it is set to false, but it may be set to true to help with debugging during development of the app. However, an app should never be released with this attribute set to true as it enables users to gain access to details of the app that should be kept secure. With the attribute set to true, users can debug the app even without access to its source code.

Properly verify server certificate on SSL/TLS

Apps that use SSL/TLS protocols for secure communication should properly verify server certificates. The basic verification includes:

verify that the subject (CN) of X.509 certificate and the URL matches
verify that the certificate is signed by the trusted CA
verify that the signature is correct
verify that the certificate is not expired

A developer has the freedom to customize their SSL implementation. The developer should properly use SSL as appropriate to the intent of the app and the environment the apps are used in. If the SSL is not correctly used, a user’s sensitive data may leak via the vulnerable SSL communication channel.

Do not cache sensitive information

Information that is cached may become accessible to other applications, and certainly becomes accessible if the device is found or stolen by a third party. Application should not cache sensitive content.


Join The Discussion