Appdome iPaaS Platform Security
This Knowledge Base article summarizes some of the Appdome platform security methods we use to protect Appdome user, mobile integration project, and Appdome-Fused mobile app users.
About Appdome iPaaS Platform Security
Generally speaking, using Appdome requires public data only. For example, Appdome users upload mobile app binaries only (not source code) and implement mobile service vendor SDKs and APIs (all of which are publicly available). Even so, Appdome uses several safeguards to ensure that mobile apps are not malicious, user and project data are safe and access is controlled. Our goal is to protect our users and protect the use of Appdome to facilitate the broad adoption of our service.
Appdome is a mobile integration platform as a service (IPaaS) that allows users to quickly add a wide variety of features, SDKs and APIs to Android and iOS apps. Using a simple ‘click to add’ user interface, Appdome allows anyone to easily add new features to any mobile app – in seconds, no code or coding required.
On Appdome, users merely upload and Android (.apk or .aab) or iOS (.ipa) app, select the new features, SDKs or APIs needed in the apps, and click “Fuse My App.” There is no development or coding dependencies, no wrappers and no limitation on the development environment used to build the app. Appdome’s technology adds the new features to the mobile app, as if the new features were natively coded to the app. Appdome is compatible with all Android and iOS mobile apps, including apps built natively and in non-native development environments like React Native, Cordova, and Xamarin.
Below are some of the measures we take to ensure this goal is achieved:
Input Validation Controls – Creating Accounts
Appdome’s iPaaS Platform uses a variety of protections against SQL injection and XSS attacks for all input fields. Appdome also requires email validation to set up accounts and uses mechanisms to guard against bots and other automated programs during account creation. To aid in mobile integration projects, Appdome also uses input validation to assist our users in avoiding common user-configuration errors that will result in invalid application outputs.
Segregated Accounts – Account Control
Each account is segregated (i.e., separate, non-visible and shielded) from other accounts by design. There is only 1 mechanism on Appdome that provides project-level visibility among users. An Appdome Team allows one user (User A) to invite and control the visibility into specific mobile integration projects in User A’s account. Only if User A creates a Team, places a mobile integration project inside the Team and invites User B to the Team, will User A and User B share a common workflow for that specific project. Teams do not provide access or visibility into the entire account of User A. No other user on Appdome can see, change or control preferences, profiles, data, projects or files inside another Appdome user’s account.
Appdome is also not a distribution platform for apps. The end of the Appdome workflow requires a user to download and distribute Fused-Apps via other distribution mechanisms.
Encrypting Appdome Platform Data at Rest – Project Data
We use MySQL on Amazon RDS and AWS S3 Buckets to store user and project data created on the Appdome platform. We use Data at Rest Encryption provided by Amazon RDS (AES-256) to protect data stored on RDS. Appdome platform data stored on AWS S3 buckets (Amazons cloud storage service), are also protected using industry standard data-at-rest encryption (AES-256) made available on AWS S3.
Encrypting Appdome Platform Data in Transit – Platform Use
All contact to fusion.appdome.com is done via HTTPS. Our SSL certificate is verified via GoDaddy. All of Appdome’s internal communication is controlled via AWS’ security groups. All contact between the application servers and the database is encrypted by Amazon.
Generating, storing and validating passwords – User Credentials
Every tenant is identified by a UUID that is unique to each user and account. In the login process, user credentials (email and password) are passed to us. From the moment of account creation onward, all communication is done via cookies, which are encrypted using iron (AES256-CBC algorithm for encryption and sha256 algorithm for integrity verification, with 256-bit salt).
We do not store plain password. We store a hashed password using pbkdf2 key derivation function with a 64-byte random salt.
The Mobile App Dataflow – No Proxy, Gateway or Hub
Appdome is a mobile integration platform as a service. Appdome is not a proxy, gateway or hub. As a result, Appdome is not in the data flow between the mobile app and the service(s) added to mobile apps on Appdome.
No End User Data
Appdome does not receive any data of, from or about mobile end users of Appdome-Fused Apps. Appdome has no access to mobile end-user data of any Appdome-Fused app.
No Appdome Server
Appdome does not rely on server-to-server integrations to achieve mobile service implementation. Likewise, there is no Appdome “box” (server or otherwise) to install and/or connect to corporate networks. Mobile service implementations completed on Appdome are contained in the Appdome-Fusion layer that is added to the mobile app.
When the Fused app is installed on the device, the Fused app sends a one-time message to Appdome with a unique installation identifier for accounting and licensing purposes. This occurs over HTTPS.
For more information on the Appdome Platform Architecture, please see this Architecture Summary.
For more information on using Teams to allow and control access to mobile integration projects, please see this article on Team entitlements.
If you have any more questions feel free to drop us a line.