Compiler vs. wrapper vs. hybrid: An honest assessment of mobile app security approaches

Picture this: You’ve built an exciting new mobile app and you’re now planning on shipping to market. When it’s released, it will upgrade the customer experience, reduce pressure on the CS team, and reduce costs. So far, so good.

But here’s the challenge: Since the app processes sensitive customer and financial data, security is non-negotiable. But time is of the essence. Every day you spend implementing security controls is another day you can’t ship to market. 

In these situations, there are several options on the table. Generally, these fall into three categories: Compiler, wrapper, and hybrid. So what are the relative pros and cons of each approach? And which is the right option for your mobile app? 

Here, we take an objective look through the options and discuss the strengths and weaknesses of each approach.

Compiler-based security: Building defenses from the ground up

Compiler-based security focuses on integrating security measures directly into the app’s source code or an intermediate representation, during the compilation process. This means security is integrated organically into the code during the build process, rather than being added retroactively when the app is complete. 

This process involves two major stages:

• First, the process starts by parsing and modeling the application's code, data structures, and control flow. 
• The compiler-based tool then performs code transformations and obfuscation, altering the instruction sequence and structure of the codebase, while preserving its original functionality. 

This makes it much more difficult to reverse engineer and tamper with the app, since key security controls are dispersed throughout the code in a complex, entangled manner. Therefore, it’s incredibly difficult for hackers to isolate and disable security features. Here are some of the pros and cons of this approach:

Benefits

• Compilers offer robust protection against reverse engineering and tampering by embedding security protections directly into the app's code.
• By eliminating the need for separate security libraries or frameworks, you can create a smaller attack surface for malicious actors to target. 
• They provide better transparency and control for the development team. During implementation, the team can use familiar debugging techniques and customize the protections to a highly bespoke level. 

Drawbacks

• The first drawback is the biggest: Compiler-based security takes significantly longer to implement than a wrapper or hybrid-based approach—and can cause disruptive delays in the development roadmap. To avoid this, organizations often take shortcuts to get the apps to market, ultimately creating less effective security than you might find in a wrapper or hybrid product.
• Similarly, you also need a developer who is familiar with the app’s source code to effectively implement the security controls. It can be very difficult to find developers that have the security expertise and specific app knowledge required to do so. 
• The code transformations and obfuscation techniques applied during compilation can increase the complexity of the app's code. This can be very detrimental to the app’s performance and create a less responsive experience for the end user. 
• Security controls in the compiler approach also need to be updated every time the app is patched or updated. This will require extra development resources, making it much more difficult to maintain an effective standard of security throughout the app’s lifecycle. 
• Overly cautious tools may flag harmless code as a security risk. This can create unnecessary refactoring, particularly when dealing with third-party libraries or legacy code that have already been thoroughly tested.

Wrapper-based security: A non-intrusive approach to mobile app protection

Instead of directly modifying the app's source code, wrapper-based security creates a secure container for the app that can enforce several security policies and controls. Generally, these are stored in a library that’s separate from the app’s source code. This means security controls can be applied after the app has been architected, without needing significant changes. 

This approach offers several potential security features, including encryption, jailbreak detection, and runtime protection. This helps protect the app from issues like tampering, reverse engineering attempts, and more. 

Here are the main strengths and weaknesses of this approach:

Benefits

• Wrappers enable development teams to quickly and efficiently add security controls around an app once the code is finalized. This can significantly reduce the amount of time it takes to ship an app to market, while still creating an effective baseline of security. 
• Wrapper-based security also tends to have a much lower impact on the performance of the app itself, creating a much more predictable and consistent experience for the end user. 
• It’s also easier to maintain security in the long run. Since security controls aren’t built into the app’s source code, they don’t need to be updated whenever the code is altered, another significant advantage over the compiler-based approach. 
• Since the security is ‘wrapped around’ the app, these products can create a much more consistent level of security across different applications, regardless of the codebase or programming language they’re built with. This means IT administrators can manage and enforce security policies for all wrapped apps from a single central location, allowing for consistent security settings and less risk of misconfigurations. 
• Wrappers can also be applied to existing apps without requiring significant development effort, making it attractive for organizations with large app portfolios needing quick security improvements.

Drawbacks

• Generally, the security in a pure wrapper-based model will be weaker than a properly constructed compiler approach. This is partly because the security protections exist in a library that’s separate from the source code, and these need to communicate with each other through quite visible channels. In theory, a hacker can isolate and disable the security layer without affecting the underlying app’s ability to function.
• Wrapper-based security is also less customizable than a compiler approach. This can make it difficult or impossible to implement security protections that aren’t either readily available or easily configurable. 
• The most basic wrapper tools tend to employ a one-size-fits-all approach to security. This means if a hacker disables the protections on one app, they could easily apply that to other apps protected by the same product. 
• A poorly designed or configured product may introduce new vulnerabilities that attackers could exploit to gain unauthorized access to the application or its data. 

Another approach to mobile app security: Introducing the hybrid model

There are clearly several pros and cons to both wrapper and compiler-based security. Compilers generally offer better security and customizability, but the time and cost taken to implement them can often be prohibitive. While wrappers can offer a wide range of effective security protections, the separation from the codebase can make them easier for hackers to disable. 

But in both cases, the devil is in the details. In practice, a compiler-approach can easily create a worse security posture if the team tries to cut corners in the lengthy and complex development process. And while some wrappers are straightforward to disable, it depends how the security wrapper is architected and how it interacts with the codebase. In short, there are no easy answers.

Yet regardless of their relative strengths and weaknesses, they’re not the only options available. That’s where the hybrid approach comes in, attempting to combine the best of both the compiler and wrapper-based approaches. 

Fundamentally, a hybrid model has a lot of similarities with the pure-wrapper approach. Generally, these products can be added to an existing app post-compile. They can also offer a range of security features ‘out-of-the-box’, requiring minimal coding and security expertise for the development team. 

But a hybrid model also includes several additional security features that aim to either reduce or eliminate the drawbacks of the pure-wrapper model. These include:

• Bindings: Hybrid models place most of their security protections in an external library, like with a wrapper. But the key difference is that some hooks and checks are integrated into the codebase. This makes it much more difficult for hackers to disable the security layer, since the wrapper library itself provides essential functions for the app. If the security layer is disabled, the app doesn’t function. This effectively neutralizes the key vulnerability of a pure-wrapper approach. 

• A unique wrapper: Pure wrappers will generally use the same security layer across all apps. But hybrid products will introduce a degree of customization, creating a unique combination of security protections for each app being protected. This makes it much harder for hackers to infiltrate all customers of the same product in one attack. 

• Code obfuscation: An additional security protection that makes it much more difficult for hackers to understand the structure and logic of a codebase. This can be applied to both the codebase itself and the external wrapper library, making it incredibly difficult for a hacker to distinguish and separate the security controls from the app’s essential functions.

Read more: Obfuscation explained: A comprehensive guide to code protection techniques

The hybrid approach introduces a small degree of extra complexity, when compared with the classic wrapper model. But in return, it offers a much more robust security posture, while still eliminating the excessive cost and complexity of the compiler-based approach.

Here’s how the three models shape up across eight main categories:

Combine the best of both worlds with a hybrid approach

Read more: 10 things to consider when comparing mobile application security solutions

When it comes to wrapper, hybrid, and compiler approaches, there are no straightforward answers. If the security requirements of your app are relatively light, there’s a good chance a classic wrapper will be the best option for you. But if you need high security controls and a particularly customized approach, the compiler option may be better–despite the extra resources it may require. 

But for many businesses, security vs. time and resources will always be a balancing act. In this case, the hybrid model is often the best choice on the table, because it combines a range of effective security controls with a lightweight approach and relatively swift deployment. This is the best way to get a robust security posture without excessive time or costs.