Despite the many advantages of “building apps for any screen”, the security risks of current bridge plugins are a veritable minefield
To some development teams, native applications are too rudimentary. Why write an application specific to one platform when you can build one that is cross-platform compatible? After all, expanding the user base is one of the most fundamental targets for software development teams.
Cross-platform frameworks definitely have a place in the future, but are they really as safe as native development workflows?
The foundational concepts that form the backbone of cross-platform frameworks diminish the tried-and-tested protection of a native operating system. These concepts bring cross-platform compatibility, but they jeopardize security through loose coupling with every supported platform. Subsequently, sole reliance on cross-platform plugins introduces loopholes and could cause plenty of insecure possibilities.
In practice, cross-platform frameworks offer the advantages of native development via application programming interface (API) plugins. First, expose the APIs in native code. Second, register these APIs as a plugin. Third, define the plugin’s APIs using the hybrid framework’s code. This creates a ‘bridge’ between the native and hybrid code. It is this bridge that can make or break the security of the hybrid application.
The hybrid development risk profile
Remember that the bridge is an extra layer of code. Going by the “keep it simple” principle, it is more likely to introduce vulnerabilities. Also:
- Any plugin marketed toward a set of platforms introduces security gaps if not thoroughly tested against the latest platform’s updates
- While plugins provide access to native features, the level of control may be limited. This can impact the final application’s ability to implement certain security measures effectively, making bypasses easy
- Updates in the native world are more frequent, so keeping a hybrid application heavily reliant on third-party plugins is challenging
- Hybrid applications often rely on communal knowledge, that is, third-party plugins that help access native features. These plugins may harbor vulnerabilities, security flaws, or outdated dependencies
- Most hybrid apps are likely created through conversion — leaving room for incomplete or insecure use of framework APIs
Keeping hybrid development secure
Without a doubt hybrid development offers compelling advantages due to the ease and speed it offers. But can you also have native-level security? By incorporating additional or alternate measures, a trade-off between ease and security can be achieved.
- Pick every plugin wisely. Does it follow basic application security principles? Review the platform-specific APIs corresponding to the chosen plugin.
- ☑ Is the native API deprecated? Has the library taken this into consideration?
- ☑ Does the library expose all the native options, especially the ones related to security?
- ☑ Does the library API work as intended on all platforms?
- ☑ Does the library assign an insecure default when the native platform does not?
- Build your own plugin securely
- Fork a plugin and support all native features by referring to the platform documents
- Periodically review the dependencies and libraries via static code analysis and dependency analysis.
- ☑ Run tools that identify insecure implementations
- ☑ Review dependencies and update as necessary
Finally, the ecosystem of cross platform frameworks for mobile development is continually growing, making it difficult to manually ensure the safety and security of these libraries as part of the software development lifecycle.
With the latest static application security solutions, mobile applications built using native or hybrid languages and frameworks can be automatically assessed against these measures. Checks for API safety, hardcoded secrets, and, Infrastructure-as-Code misconfigurations, are a core component of the engine that forms the backbone of these solutions.
