Fliplet has numerous security features that you should use and test before launching your app. This article explains the security features you should use, common types of security tests, and what we recommend you do before proceeding with a security test. A full list of security features can be found in the App Security article.
This article will cover the following:
- Fliplet security features
- How to test your app
- Analyzing your security results with Fliplet
- App security settings & testing suggestions
Fliplet Security features
To secure and test an app built with Fliplet you should use the following features:
- Suitable authentication components, such as the Login component or the SSO component
- Configure app security feature to limit access to screens within the app depending on the user successfully logging in and meeting certain security requirements such as being a type of user
- Configure data source security rules to limit access to data. Usually, this includes limiting who can read, write, update or delete records. It can also include enforcing rules such as users only being able to retrieve their records and not other users’ records.
By enabling, testing, and maintaining these 3 security features the security of your app can be significantly improved.
Additional security features that you can utilize are:
- Encryption features
- Lock component
- MDM to control the distribution of the app
- IP restrictions to control access to the web app
If you have questions or suggestions about our security features please get in touch with our support team.
How to test your app
This section covers the different types of tests and what you may want to include if you’re testing an app from Fliplet.
Scope
Fliplet produces 3 types of apps:
- iOS native app (IPA)
- Android native app (APK)
- Web app hosted by Fliplet
You’ll need to decide what platforms you’ll be using before performing a security test.
Penetration testing
A penetration test is an authorized simulated cyberattack on Fliplet systems (APIs, Studio, Web apps, or Native apps), performed to evaluate the security of the Fliplet app and the underlying infrastructure.
This type of testing is the most common as many companies require their apps are penetration tested in order to comply with industry standards and certifications.
Before organizing a penetration test you must tell us:
- Scope of the test you intend to carry out, including the affected resources
- Source IPs for all incoming traffic from your systems to our infrastructure
- Start and end date (2 weeks notice is required)
- Point of contact (full name, mobile number, and email address) for emergencies
Please forward this information to your support contact so they can notify our infrastructure team.
If you do not tell us it is likely you’ll be breaking the terms of service with Fliplet and their infrastructure providers because you’ll be simulating an attack on the app which will probably result in your app or API access being suspended or throttled and possibly reported for inappropriate or dangerous behavior.
How to test native apps
Whereas testing web apps is relatively easy given today’s development and debugging tools offered by modern browsers, testing native apps requires a little more setup.
We recommend carrying out native testing only once the app security checks have been set in Fliplet Studio to ensure you’re testing the app bundle right before it’s uploaded to the various stores for end-user distribution.
Depending on the required distribution mechanism you may need to run more thorough checks, e.g. distributing an app on the App Store should go through more aggressive checks than apps distributed to a private MDM enterprise where the devices list is securely managed by your organization.
To build an app you’ll need to gain access to the iOS and Android apps via Fliplet Studio then download them and share them with the person testing your apps.
Start by requesting an unsigned build for your app via the “Publish” tab in Fliplet Studio; once you have requested a build you should be seeing your submission being marked as completed within 15 minutes with download links to get the IPA file (for iOS) or APK file (for Android) depending on the platform you have requested to build. Those files you download can be installed on your device to commence with the testing.
Apple iOS apps
Apple iOS devices require all apps installed must be signed with a valid Apple Developer account and potentially approved by Apple for distribution. In order to test an iOS app before Apple has approved it, you’ll need to sideload the app onto a device. If you do not know how to sideload an iOS app then we recommend you search Google or wait until the app has been approved by Apple.
Fliplet does not produce TestFlight apps. We offer app testing via Fliplet Viewer, an app you can find in the app stores.
Android apps
Android apps are far easier to sideload, instructions can be found on Google.
How to test Fliplet APIs
Fliplet apps use a limited range of Fliplet APIs. The number of API endpoints being used can vary wildly depending on the features your app makes use of. We recommend customers assess an app to determine what APIs it uses by monitoring an app’s use via a proxy or network monitoring tool. These tools can also help you to monitor the network load.
How to assess the scope of your testing
Ideally, the app should be used by the tester to determine what specific features of the app must be tested to ensure the app is secure. This testing can include watching the network traffic to determine what Fliplet APIs and 3rd party services the app communicates with.
Based on this assessment the security tester should be able to suggest a scope and provide a timeframe for how long the test will take
Analyzing your security results with Fliplet
After your test has been conducted please contact Fliplet to organize a review of your test results and to discuss any remediation required. We can advise you if the issue is related to:
- A scope definition or misunderstanding
- Poor configuration of Fliplet security features
- By design due to how Fliplet works
App security settings & testing suggestions
Depending on the complexity of your app, there may be a multitude of elements you want to check and verify before the app is distributed to your users. Read through the following sections to validate what applies to your app and what doesn’t.
1. Vulnerability assessment
You should always run a vulnerability assessment of your app based on the OWASP Top 10 standard, which defines a common list of security risks that web and native applications can be exposed to.
1.1 Custom code
Developers adding custom code to your apps should be mindful when it comes to security and validate all code they implement to ensure it follows good standards such as OWASP.
2. Level of access
Apps can have different levels of user access depending on your setup, e.g. if your app has a login system (such as the data source login component or single-sign-on component with SAML2) you will need to test for more scenarios than just anonymous users. Likewise, if your app has specific users being flagged as “admin users” hence capable of making changes to your app then you may want to run more checks on those additional scenarios.
3. App security
Apps can define screen-based security through the “App settings > App security” section of Fliplet Studio. Make sure proper security is set for all screens requiring a login.
Likewise, if your app includes admin screens to be used by admin users make sure that a custom rule to only allow those users have been set up.
Moreover, IP-based whitelisting (or blacklisting) can be set up to further enhance the security when your app is distributed as a web app.
4. Data sources
4.1 Access rules
Proper access rules should be configured at all times for the data source in use by your apps. Make sure that each data source is reviewed and access is given only when the correct conditions are met, e.g. only logged-in users are allowed to read or perform a certain action.
Fliplet will not take any responsibility for misconfigured security for data sources, so it’s very important that you go through the list and ensure everything is set up correctly.
4.2 Bundling
If a data source has been flagged for being bundled it’s going to be available for offline use by the apps using it. However, that also means the data source is going to be bundled in the IPA/APK file uploaded to the App Store or Google Play.
This can result in an attacker being able to access such data despite not actually having proven its identity with Fliplet’s backend, therefore you must only bundle data sources that do not contain sensitive data in it.
4.3 Encryption
Fliplet recommends that Data Sources containing sensitive data are encrypted whenever possible.
We provide an extensive list of resource material to ensure you set up encryption on both Fliplet apps and data uploaded to Fliplet’s backend via the Data Integration Service.
5. Features
Apps can have a broad range of features that introduce different security issues. The main features to assess are any features:
- Retrieving data from Fliplet’s APIs such as forms and lists
- Writing data to Fliplet’s APIs such as forms, chat
- Processing data with Fliplet’s APIs such as security components like login and SSO
Related Articles