Skip to main content

Security of OutSystems applications

OutSystems

How can I create secure mobile apps?

When your apps leave the safety of your data center or secure cloud environment to be installed on the mobile devices of your workforce, a new set of security challenges arise.

OutSystems takes security very seriously, both for mobile and for web applications, and is committed to following best practices for web and mobile security, namely those defined by OWASP.

Creating secure mobile apps requires implementing multiple layers of security - in the mobile device, in the backend, and in the communication channel.

Basic principles for mobile security

When it comes to mobile security, the single most important principle to consider is that any mobile device can be compromised. Your efforts should, therefore, be focused on keeping your data safe and your secrets secret.

Secure device and apps

Secure device access

Two important security checks should be applied to the device itself to make it harder for attackers to gain unauthorized access to your app. First, apps should check whether the device has privileged access as a result of being rooted or jailbroken. Second, the app should check that the device has a security lock mechanism such as a pin, pattern, or passcode.

The Secure Device Plugin in OutSystems Forge can be used to validate that the device running the app is sufficiently protected. If the device is compromised, a message is shown to the user and the app exits immediately before displaying any app data.

Another approach is to use a Mobile Device Management (MDM) tool, typically part of an organization’s Enterprise Mobility Management (EMM) suite. MDMs allow you to manage device configurations and operating system updates, ensuring that apps don’t run on devices with privileged access. MDMs can also apply policies to the device to require a passcode to access managed apps, corporate email or the web.

Secure app access

After addressing device access, the next consideration should be securing access to the app.This means considering both how you distribute your app, and how you give access to it.

App distribution

While consumer apps are distributed by official app stores (iTunes App Store, Google Play), for employee (B2E) applications this is usually not the case. Instead, these apps are distributed using an enterprise app store where security policies can be implemented to control user access. Mobile App Management (MAM) tools, whether standalone or part of an EMM suite, provide these capabilities and allow their customers to brand their enterprise store apps with their logo and color schemes.

OutSystems provides an app that can be easily extended to implement MAM functionality, allowing users to access a catalog of apps that match their user profile and install them on their device.

Authentication

The way apps authenticate users  can be divided into two approaches, local or federated authentication.

Local authentication is implemented by default for mobile apps built with OutSystems.  The user provides a username and password that is validated server-side, creating a single sign-on context enabling access to other apps that share the same security context. This is important for employees who may need to use several apps to get their job done.

With OutSystems you can implement alternate login flows to authenticate users with a locally stored passcode or using the Touch ID plugin. In B2E scenarios it is also common to authenticate users with identity management provider systems like Active Directory or other LDAP systems. These can be easily configured with OutSystems.

Federated authentication is typically implemented by identity providers with the OAuth and SAML protocols. OAuth is more common for B2C apps that use social networks as their identity providers. Pre-built OutSystems components, for example the Google Login Plugin, make it easy to integrate with OAuth identity providers. SAML is more common for B2E apps and can be implemented using, for example, the IdP component.

Another option to consider is that MAM tools often provide SSO capabilities for mobile apps, usually with the ability to connect to your identity provider.

Secure data at rest

Data stored by mobile apps on the device itself is an obvious target for an attacker.  There are a number of approaches that can be adopted to minimize the exposure.

Store as little information as possible

The most effective approach to securing data on the device is to avoid storing any data at all. In reality, whether to support working offline or to improve the user experience, this is not always possible. As a general rule, only store data on the device when it is absolutely necessary.

Encrypt the data you store locally

In situations where you need to store sensitive data locally, the safest approach is to ensure the data is encrypted. Data encryption and decryption incurs overhead, therefore encrypt as little as possible to avoid impacting the end user experience. OutSystems provides a variety of different pre-built components to simplify the process of encrypting local data.

Keep information safe from prying eyes

While you might take care encrypting data stored locally, this information may need to be shown to the user in human-readable form. In the event that an attacker grabs an unlocked device, they might be able to read confidential information from the app, even if it is running in the background. To keep the information safe in this situation you can use the Privacy Screen Plugin. This pre-built component hides the information of the app once it is sent to the background, forcing the user to re-authenticate when the app resumes.

Be prepared for reverse engineering

If an attacker gains access to the package of your app, they can view the contents, including backend addresses, app code logic, and resource files. Do not place any sensitive information in your static files. HTML, CSS and JavaScript are plain text files and, therefore, easy to read and interpret. If you have sensitive information that must stay in client-side code, extract this information into a separate script file that your app imports, and obfuscate using tools like jscrambler or JavaScript Obfuscator.

OutSystems internal JavaScript libraries are obfuscated and minified, making it much harder for an attacker to read and interpret.

Additional app resources

Other app resources (PDFs, Excel files, etc.) that are bundled or fetched and stored locally are also at risk. Consider implementing security mechanisms within those files such as password protection or file encryption.

Detecting breaches and taking action

No system or app is 100% secure. We hear about security flaws in iOS and Android operating systems, phone manufacturer software or protocols that compromise private information. Examples of the impact and consequences of these are constantly in the news.

Big tech firms are able to invest in keeping their assets secure and are quick to react to security issues. Not all firms can afford this investment. Most security risks are handled by OutSystems, and most of them happen in the backend. With 1-click publish and app hibernation, issues are more quickly solved with OutSystems versus manually updating versions in the app stores.

Device decommission

When a device is stolen or an employee leaves the company you need to take action. Removing user access is not enough most of the time because the app is still installed on the user’s device and data may still be stored locally.

You can use the device plugin which is present in every native app created with OutSystems and store the device’s UUID to manage the devices and users of your applications.

You can also implement safety mechanisms in the application to remove any data stored locally when the device is blacklisted, either because it was reported stolen or because the employee left the company.

If you are using an MDM or MAM this becomes easier as most of these include tools to perform remote app removal and remote data wiping.

Secure data in transit

In addition to securing the device and the app, the channel that transports sensitive information between the backend and the device should also be considered.

Mobile applications created with OutSystems require that all communication uses the HTTPS protocol with a valid certificate. This ensures that all data transferred across the channel is encrypted.

Take care of the man in the middle

Even with an encrypted channel you should prevent man-in-the-middle attacks by validating the origin of the information you receive. This is achieved with a technique called SSL pinning which validates the certificate used to encrypt the information in the communication channel matches the one you expect.

Implementing SSL pinning in OutSystems mobile apps is simple using the SSL pinning plugin.

Reaching your corporate network

Many times your mobile apps need to communicate with a backend that resides behind firewalls in the corporate network. The usual approach is to use a VPN to securely access the corporate network. This means that a VPN configuration needs to be set in the device so the applications can reach the backend.

Operating systems allow creating these VPN connections but this imposes not only a configuration issue - the end user needs to know how to configure it and to switch the connection on before using the app - but also a security issue. A system-wide VPN configuration means that any app that runs on the device also has access to the corporate network.

MAM tools allow the configuration of per-app VPNs, which solve both problems. Since the configuration is bundled in the app, the user no longer needs to perform this configuration on the device. When the app starts, the VPN connection is established automatically. Only that app can use the VPN tunnel to communicate with the backend, preventing other apps from accessing the corporate network.

Secure the backend

One of the most exposed parts of a mobile app, especially in B2C scenarios, is the backend, as attacks can come from both the mobile app and also outside of the mobile app. In fact this is the top risk identified by OWASP for mobile security.

To secure the backend, OutSystems enforces a strict HTTP transport security policy for mobile applications. Additional security mechanisms prevent brute force, code injection, and other type of attacks. An anti-tampering mechanism prevents users from elevating their access in authorized requests by anonymizing those requests. Most of these mechanisms require no developer intervention. Others are proactively signaled by OutSystems during the development phase so that the developer can take the appropriate action.

Follow this link to learn more:

How OutSystems helps you develop secure applications

  • Was this article helpful?