Mobile App Secure Development Guidelines and Mobile App Platform Requirements were compiled on the request of the Ministry of Economic Affairs and Communications and for the description of activities specified in the Government of the Republic’s action programme (ratified in 2011). The aforementioned activities include developing security requirements for e-services used in mobile devices and specifying requirements for operating system and browser interoperability.

The purpose of this document is to provide general requirements and guidelines to be followed when developing applications for mobile devices, both for public procurement and for private business purposes. The development guidelines are meant as a tool to be used by both the contracting entity and the developer.

This document touches several topics connected with mobile app development and describes a set of guidelines that must be considered during planning and development for the end result to be a secure and usable mobile app.

Mobile App Secure Development Guidelines were developed in the scope of the project “Nutikaitse 2017”. It was launched in November 2013 by the cooperation of the public and private sectors. Its purpose is to contribute to the secure running and use of mobile e-services and solutions in times when computer use has moved to people’s pockets.

The project is coordinated by the Look@World Foundation. All connected parties of the cooperation agreement wish to raise security awareness and skills of mobile device users, developers, and sellers. By doing so, to further easy access to secure and usable softwre.


Attention must be given to user authentication. It also has to be ensured that the user session of a user authenticated in a mobile app would be protected and impossible to take over.

In secure handling of passwords, it must be considered that in addition to security measures employed in app development, much is dependent on how users protect their own devices, i.e. on the screen lock and PIN codes chosen, on biometrical authentication methods chosen, on using different passwords for various services, and on how users physically protect their devices to keep them from falling into strangers’ hands or to keep them from getting lost.

  1. Strength of Authentication Mechanism

    The strength of the authentication mechanism used to enter an application must be contingent on the sensitivity of the data the application processes (e.g. personal information, financial operations). The combination of the application’s own username and password is the weakest authentication mechanism. When users choose their passwords, it is best to give instant feedback on the strength of the inserted password.

  2. 2-Factor Authentication

    If necessary, 2 factor authentication should be considered, i.e. adding additional security measures to the authentication process, e.g. SMS verification codes, using a special key generation application or a PIN calculator. If necessary, CAPTCHA code may be added for human detection.

    If using verification codes, it is advisable that the developer of the application or the client inquire from every target market’s mobile operator whether the local operators and service provider used for sending SMSs have corresponding service contracts to ensure that SMSs containing authentication codes reach end-users.

  3. Delegated Authentication

    When using delegated authentication (e.g., OAuth), one should use the latest version of the corresponding standard.

  4. User Identity

    Because a mobile device may have multiple users, the identity of the user should be checked, rather than that of the device’s.

  5. Passwords Masking

    It’s worth reconsidering whether masking characters in password entry forms should be done. Leaving them visible may improve both usability and security as doing so permits people to choose more complex passwords.

    Further reading:

  6. Password Alphabet

    A user should be able to use any Estonian alphabet character in a password.

  7. Input Pattern

    Gestures made on the screens of mobile devices leave traces and smudges, from which it may be later possible to identify patterns or input. If necessary, security concious interfaces should be designed such that they reuse areas of interest to obfuscate previous gesture patterns.

  8. Authentication Context

    In order to make authentication more secure, it is possible to follow context: the device’s identifier, IP-addresses, etc. If the application identifies an unanticipated change in the context (e.g. a change in the IP-address location country), it is advisable to implement additional authentication measures.

  9. Password Storage

    Passwords should never be stored in plain text. If it becomes necessary to store passwords on the device itself, they must be stored using secure storage mechanisms provided by the host platform.

    However, authorization tokens should be preferred to storing passwords, as those won’t leak the original password in case of a security breach and can be revoked independently.

  10. Authorization Tokens

    After the user has been initially identified in the application, authorization tokens should be used instead of the password. These must be securely saved on the device, they must have a predetermined expiration date, and they must also be possible to invalidate remotely by the backend server. It must be ensured that authorization tokens would expire as frequently as is practical (also dependant on the purpose of the application).

  11. Session Identifiers

    Any used session identifier should be such that it can’t be guessed, constructed nor derived from other known identifiers.

    It has to be taken into account that the output of pseudorandom number generators (PRNG) depends highly on the entropy of the initial seed value and the quality of the PRNG itself. Make sure to use a cryptographically secure random number generator provided by the platform for session identifiers.

    Further reading:

  12. Changing Passwords

    A user should have the option of changing passwords within the app. Each password picked by the user must be checked for sufficient complexity (including the complexity of visual passwords).

  13. Identification Consent

    Consent for transmitting personally identifiable information, incl. identification information, should be stored and retrievable later.

  14. Mobile-ID Confirmation Code

    The Mobile-ID confirmation code shown for authenticating or digital signatures should be positioned so it’s visible clearly and remain visible until the authentication is complete. The ability to compare the code shown in a mobile app with the one shown on the Mobile-ID SIM-card application before entering one’s PIN is required by the Mobile-ID standard and permits the user to confirm whether they’re signin in to the service they’re expecting. We shouldn’t cultivate a habit of ignoring it.

  15. Mobile-ID Certificates

    It may be convenient for the user if the mobile app notifies them of the expiration of their Mobile-ID certificates should those, for example, expire in the next 30 days.

  16. Mobiil-ID Notifications

    Informational and error messages shown during the use of Mobile-ID should be made understandable to the user and shouldn’t contain excessively technical details.

  17. Session Logging

    User session lifecycle events, such as signing in, signing out and so on, should be logged.

  18. Signing Out

    A user must have a way to sign ouf of the app and revoke all authorization tokens. That includes ending all authenticated sessions.

Data Protection in Device

In order to minimize the risk of data leakage – including personal data leakage – from a device to third parties, corresponding risk minimization measures must be deliberated and employed.

In the EU, it is mandatory to obtain the user’s agreement to process their persona data, including collecting authentication data, unless the law states otherwise. Users must information or references to on how their personal data is processed from within the app and what it is used for. Personal data processing policies must be described in a “privacy policy”.

  1. Data Security Level

    Classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, personal data, location, error logs, etc.). Process, store and use data according to its classification. Also, pay attention to to the security of sensitive data passed to external API calls.

    For software made by or for the public sector, sensitive data should be classified with the help of IT Baseline Protection Manual.

  2. Personal Data

    Handling sensitive personal data, such as medical data, needs registering at the Estonian Data Protection Inspectorate (page in Estonian).

  3. Principle of Least Knowledge

    During planning it’s advised to follow the principle of least knowledge, that is to not collect more personal information than is necessary for the functioning of the app. That will save having to ensure their confidentiality.

  4. Data Lifetime

    When storing data it should also be clear how long should the lifetime of any particular data be, and when can it be automatically purged from either volatile or non-volatile memory.

    Location or any other sensitive personal data should not be kept in the device longer than absolutely necessary.

  5. Data Lifecycle Security

    The whole lifecycle of a piece of data should be taken into account, starting from when it was first obtained through the network, through temporary storage on the device or memory, up to non-volatile storeage, incl. backup, and ending with deletion.

  6. Data Encryption

    Sensitive data, especially authentication tokens and passwords, can only be stored on the device in encrypted form. When possible, save them to read-only and temper-proof areas.

  7. Crypto-Algorithms

    When choosing a cryptographic algorithm, prefer well-known, publicly vetted algorithms (such as AES), and optimal lengths of cryptographic keys.

  8. Crypographic Method

    When storing data on the mobile device, use the crypto-APIs provided by the host platform or by any well-trusted 3rd party instead of inventing your own.

  9. Data Store

    It should be assumed that any shared storage space on a device is unsafe and untrustworthy and any data stored there may be unexpectedly modified or leaked. In other words, the integrity, confidentiality and availability of that data is comproimsed.

    • Device RAM and temporary storage areas are possible leak channels if they’re shared with other apps. Ensure such temporary data isn’t stored in publicly readable and writable directories.

    • Data may leak also through non-temporary shared storage, such as the call log, address book or photo gallery. For example, a user may inadvertently share personal data through location data stored on images.

    • An app’s configuration file may be changed by other apps if stored on a publicly writable way. Even if the configuration lacks private information, it still often is important to withhold the integrity of it, lest it can become a attakc vector.

  10. Data Deletion

    It’s fundamentally difficult guarantee proper removal of data from cloud services or from the device’s local storage. That should be considered as data gets stored — it may be available indefinitely.

    When utilizing cryptography, an algorithm should be chosen such that it doesn’t weaken over time faster than the data loses it’s value.

  11. Remote Data Deletion

    For extra security a developer may add the ability for a user to delete their data remotely from devices they’ve installed the same app. While useful, it may entail new risks, so ensure strong authentication to mitigate those.

  12. Data Backup

    Only encrypted or hashed versions of passwords and authorization tokens must be included in regular data backup. It must be taken into consideration that the strength of any encrypting or hashing algorithm weakens over time. Thus, backup copies containing encrypted data must not be stored longer than the effective use time of the encrypting algorithm.

  13. Privacy Policy

    A mobile app should have privacy policy that describes how personal data is handled and secured. The policy should be easily accessible from both the screen used to accepting it and from the app afterwards. The policy should be written in simple language for people to easily understand.

  14. Input

    A mobile app should verify all input data and either inform the user of any mismatches or convert them to a suitable form.

  15. Digital Signature Algorithms

    It’s suggested to use the BDOC container format for digital signatures. Signing itself should use the newer elliptic curve (ECC) algorithms, which are compulsory since Jan 1, 2015.

Data Protection on Network

When using network connections, one should remember that data transfers over the network must be through encrypted channels because not all parts of network are guaranteed to be under the control of the user or the developer of the application.

These days, a large umber of mobile apps require access to the network and backend servers to function properly. If those servers or network channels are not sufficiently secure, they can be used as attack vectors.

  1. Transmitting Data

    Data must be transmitted only over secure channels (such as SSL/TLS).

    If possible, only well-known protocols and their implementations should be used. The fewer protocols are in use at once, the easier it is to ensure their robustness and security on both the receiver and sender side.

    Most of the client-server use-cases today can be solved by using HTTP over SSL (HTTPS) with libraries and implementations available on all platforms.

  2. Certificate Trust

    Only security certificates signed by trustworthy certificate authorities may be used. One must also be careful in allowing self-signed security certificates. SSL chain verification in an application must not be ignored or excluded.

  3. Certificate Validation

    An SSL data channel should be created only after confirming the identities of both parties by checking their security certificates and their authenticity.

  4. Certificate Expiration

    An app’s user interface should make it possible for a user to confirm the expiration date of a certificate. Generally, though, that capability should only be brought out in potential error cases.

  5. Downloading Data

    Upon opening an app, it shouldn’t immediately start downloading large quantities of data, but instead confirm with the user if it’s okay to do so. They might be on a limited or highly priced data plan.

  6. Transmitting Personal Data Over Text

    Sensitive personal data must not be sent over SMS, MMS or through device notifications, as those may be intercepted by third parties and the former, especially, are not encrypted.

  7. Near Field Communication (NFC)

    To mitigate the risk of eavesdropping on a near field communication (NFC) transmission, encryption should be used. Even though NFC is designed for short ranges, it’s still possible to listen in meters away (up to 10m for active and 1m for passive devices).

  8. Security Testing

    Backend servers and their APIs should be regularly and systematically tested for security issues with a combination of automatic penetration tests and static analysis.

  9. Server Hardening

    Backend servers should be set up with a hardened configuration: the operating system, webservers and other components should be kept up-to-date; with no unnecessary software running or plugins installed and all other network access ports closed.

  10. Denial of Service (DoS) Attacks

    Using user-based or network-based access controls may help mitigate or handle a DoS attack.

  11. Backend Server Logs

    Backend servers should keep logs around for incident discovery and response. When necessary, they may also contain logs from client apps, within the law of personal data.

App Protection

When creating an application, one must make sure that used third party ready-made software components are secure. One also has to ensure that related online services are secured.

Mobile apps may be given automatic access to paid functions such as phone calls, SMSs and MMSs, roaming data, NFC payments, etc. In creating such privileged access applications, possible fraudulent uses must be considered particularly carefully. Applications must be analyzed for potential weak spots and the opportunities they give to possible attackers and how to limit access to paid services.

Secure distributing of applications through official distribution channels is important. Official application stores should be preferred, for they provide the user with the updates and tend to provide additional safety checks and measures.

  1. Application Permissions

    In order to work on a mobile device, applications tend to need a set of permissions from a user. Before requesting any particular permission, its necessity should be carefully considered. It’s safer to refrain from asking for permissions “just in case” if they are actually not necessary for the application to work. The user should have access to precise explanations why an app needs its permissions.

  2. Authorization Tokens in Code

    Passwords and other non-publically accessible information must not be kept in the source code of a mobile app. It’s fairly easy to disassemble the source code or extract other information from the executable on the device. Any binary shipped to customers must really be considered public space.

  3. Security Testing

    The security of an application must come from the design of the application and from the development process involving regular security tests, and not from the secrecy of the source code, security flaws, communications protocol, network address, etc. Secrets have a tendency to come out eventually.

  4. Component Security

    As far as possible, the security and authenticity of all the used pre-made components should be checked. Make sure whether the components come from a reliable source and that they do not contain possible back doors and malware. This includes both libraries and source code copied from the Internet.

    It is better to separate components obtained from other parties in such a way that the security holes in them would not put the application at risk. For example, integrated web views or advertisement banners should not be given access to the application’s internal functions.

  5. Component Upgrades

    Security patches and upgrades of used premade components must be followed. Whenever they appear, the application must be upgraded correspondingly.

  6. Third Party Data

    Special attention should be given to data accepted from or sent to all unreliable third-party applications (e.g. advertising software)

    As with components, data should be considered unsecure by default. Whether the structure, types, and values of the data correspond to expectations should be checked prior to using received data. Whitelisting, or only permitting suitable data, is generally more secure than blacklisting, or banning unsuitable data. In case of the latter, something unanticipated may get through.

  7. Terms of Service

    There are two main ways to confirm the terms of service with the user:

    1. At the time of installation;
    2. At the time of running, before transmitting sensitive personal data.

    Legally the correct approach would one of “opt-in”, as opposed to “opt-out”. That is, the user must knowlingly, and through a concious action, agree. Agreement by default, thereby through inaction, isn’t considered accepting the terms.

  8. User Identification

    Users could inadvertently be identified through indicators never meant for authentication.

  9. Terms of Service Contradictions

    Terms of a mobile app should not contradict the terms of any other service the same provider offers. For example, on the service’s web page. The described terms of service and privacy policy need to apply for the specific app, not to the parent company as a whole.

  10. Authentication for Paid Services

    All requests to backend servers that make use of paid services should be authenticated.

  11. Confirmation of Paid Services

    All actions that will result in charging the user for paid services should be preceded by a warning and confirmation. That applies to large data transfers, where it’s reasonable to suggest using local Wi-Fi. People may be on limited data plan or using roaming where transfers may be expensive.

  12. Minimizing Paid Service Use

    Use of services that may cause charges by the app should be monitored and minimized. For example, network transmission should be kept to a minimum.

  13. Application Stores

    Even though delays resulting from app stores’ approval processes must be taken into consideration, most of these stores are also capable of quickly remotely removing applications if unsecure code and risks are discovered. Thus, it is advisable to distribute apps via app stores.

  14. Software Upgrades

    It must be ensured that after an application is ready and made public upgrades can still be added to it and that at least upgrades patching security problems would regularly be available.

  15. Manufacturer Information

    It is advisable to include information regarding the developer or owner of the application (including general and customer support contact information).

  16. Security Reports

    There should be ways for a user to notify the author of a mobile app about security issues, for example, through a dedicated email address starting with “security@”.

  17. Code Interpreter

    The code interpreter included in the application must work with minimal required rights, so that the application could not be used for actions requiring increased rights (e.g. in case some malware attempts to use the application or modified input data is entered into the application).

  18. Code Interpreter Sandbox Mode

    Code interpreters in an app should be tested against attacks and preferably be put in sandbox mode to limit.


OWASP Application Security Verification Standard (2014)
Mobile app
A software program developed or ported for running on a mobile device.
Mobile device
A small computing device (generally small enough to be hand held) that differs from a generic mobile phone by having functionality similar to a regular computer. Mobile devices often have a touch-sensitive display, network capabilities and an operating system that supports 3rd party software.
Mobiil-ID is a mobile-based digital identity solution based on the Estonian ID-card for authentication and digital signatures.
Personal Data
Personal data are any data concerning an identified or identifiable natural person, regardless of the form or format in which such data exist.

Protection of personal data, incl. sensitive personal data, is regulated by the Personal Data Protection Act.

Sensitive personal data
The following are sensitive personal data:
  • data revealing political opinions or religious or philosophical beliefs, except data relating to being a member of a legal person in private law registered pursuant to the procedure provided by law;
  • data revealing ethnic or racial origin;
  • data on the state of health or disability;
  • data on genetic information;
  • biometric data (above all fingerprints, palm prints, eye iris images and genetic data);
  • information on sex life;
  • information on trade union membership;
  • information concerning commission of an offence or falling victim to an offence before a public court hearing, or making of a decision in the matter of the offence or termination of the court proceeding in the matter.

If a processor of personal data has not appointed a person responsible for the protection of personal data provided, the processor of personal data is required to register the processing of sensitive personal data with the Data Protection Inspectorate.

Protection of personal data, incl. sensitive personal data, is regulated by the Personal Data Protection Act.

API (Application Programming Interface) is a set of routines and protocols for building software and applications.
Backend service
A server outside of the mobile device used by the mobile app provider to supply further capabilities or functionality.
A “Three-level IT baseline security system” security standard developed for the Estonian public sector. According to Government Regulation no. 273 of 12 August 2004, ISKE is compulsory for state and local government organisations who handle databases/registers. Preparation and development of ISKE is based on a German information security standard “IT Baseline Protection Manual” (IT-Grundschutz in German).