Mobile applications have become the front door to some of the most sensitive systems organizations operate—banking platforms, healthcare tools, and the APIs that power them all. But that front door is increasingly under siege. Attackers no longer need to breach a fortified backend when they can simply reverse engineer a mobile app, clone it, automate it, or run it in a compromised environment to slip past defenses that were never designed to question the app’s authenticity in the first place. The result is a security gap that lives precisely where most teams aren’t looking: the space between the device, the app, and the backend services that assume both can be trusted.
To unpack how this gap forms and what it takes to close it, VMblog sat down with Joel DeStefano, Senior Product Manager at Guardsquare, a company focused on mobile application security. DeStefano breaks down why pre-release scanning—while essential—isn’t enough once an app lives “in the wild,” why even Apple’s famously locked-down iOS ecosystem doesn’t make individual apps immune to tampering and repackaging, and how organizations can shift from merely detecting risky mobile behavior to actively enforcing trust at the point of API access. The conversation offers a practical look at where mobile risk really hides, and what it takes to build protections that hold up in production rather than just on paper.
++
VMblog: What do modern mobile app attacks actually look like in practice—and how do they exploit the gap between the app, the device, and backend APIs?
Joel DeStefano: That’s a great question to start with. Modern mobile attacks often target the application as an opportunistic path into accounts, sessions, APIs, and business logic. Given an opportunity, attackers may try reverse engineering the app, tampering with runtime behavior, abusing accessibility services, automating API calls, stealing or replaying sessions, or running the app in a manipulated environment.
Probably the most glaring gap where exploitation occurs is between the frontend (client-side) and backend (server-side). The backend may assume the app, device, and user session are all trustworthy, while the attacker is interacting through a modified clone app or an automated version (like a malicious bot). To close that security gap, you need to ensure that the frontend mobile app is authentic at the point of connection to backend services – the API.
VMblog: Why isn’t scanning enough to protect a mobile app?
DeStefano: As with any application security strategy, scanning is essential because it helps development teams find security issues earlier in the process. It’s typically easier and cheaper to fix an issue when the context of building that code is still fresh in the mind of the developer. Continuous scanning (AKA mobile application security testing or MAST) helps teams ensure proper hygiene and secure coding practices.
But with mobile applications in particular, things get more complicated once the app is released. Unlike a web application that lives on a server surrounded by network security controls, a mobile app lives in the wild. It might be installed on a rooted device or emulator. A malicious actor might use special tools to inspect, reverse engineer, tamper with, or automate it. While scanning helps reduce risks that arise pre-release, mobile apps also need built-in protections that help make them harder to attack post-release.
VMblog: What kinds of problems should teams be looking for before an app goes live?
DeStefano: There are a number of critical mobile app security issues that continuous, automated scanning can help surface during development. Teams should be on the lookout for things like embedded credentials, insecure data storage, weak cryptography, misconfigured network connections, vulnerable third-party libraries, debug artifacts, excessive permissions, and code patterns that make reverse engineering easier. These are all common mobile app problems that can lead to real world abuse if they’re allowed to slip through into production.
VMblog: iOS is often considered inherently secure. Where does that perception fall short in real-world threat scenarios?
DeStefano: First, I think it’s important to understand that there’s a difference between OS or device security and mobile application security. iOS has earned a reputation for being a strong platform. But the OS-level protections that Apple provides don’t make iOS apps secure by default. iOS may protect an app against some risks, but attackers can still target app logic, mobile APIs, sessions, apps in jailbroken or instrumented environments, repackaged apps, exposed secrets, and weak client-side controls. Complementary OS-level controls are helpful, but they are not a replacement for dedicated protections at the application level. Even on iOS devices.
VMblog: How do app tampering and repackaging create business risk?
DeStefano: Unprotected mobile apps are vulnerable to reverse engineering and malicious modification. Attackers can use specialized tools to tamper with a legitimate mobile app’s code, change its behavior, and then repackage it as a cloned version that looks and functions like the real thing. These cloned apps help bad actors bypass security controls, commit fraud, steal sensitive data, abuse APIs, and exploit back-end services.
The potential business risks that come from inadequate security against reverse engineering, tampering, and repackaging are wide ranging – including user churn and app uninstalls, lost revenue, regulatory penalties, legal costs, and negative publicity that damages the company brand.
But the actual risk to the business depends on the nature of the app itself; all things are not equal. If it’s a mobile banking app, the obvious threat is monetary losses. If it’s a mobile gaming app, maybe tampering allows some players to cheat (which undermines the game’s popularity and trust in the developer). On the more extreme end of the risk spectrum, a compromised mobile app that controls a medical device like an insulin pump could feasibly put human lives in danger.
VMblog: What are the trade-offs between runtime protection, wrapper-based approaches, and compiler-level security? Why do they matter in production?
DeStefano: The ultimate goal of security is to provide the highest level of protection without impacting a mobile app’s performance or the experience of an end user. That’s the brass ring we’re all reaching for, and some approaches achieve this better than other approaches.
Runtime protection are security checks that get inserted into the code itself to help detect and respond to dynamic attacks that occur while the app is running. Common threat examples include tampering, hooking, debugging, or compromised environments. Runtime protection is often coupled with protection against static analysis (attacks that happen when the code isn’t running). We call this “code hardening” – different forms of obfuscation and encryption that make mobile application code much harder to read, analyze, and reverse engineer.
Then there’s the question of how those mobile app protections get implemented. Wrapper-based approaches can be easier to apply after development, but they’re not deeply integrated with the application code and only offer a single layer of security for a threat actor to bypass. Compiler-level security, on the other hand, gets applied during the build process. This allows protections to be integrated more deeply and directly into the app itself. These differences matter in production because teams need protection that remains resilient as the code evolves and as attackers adopt increasingly sophisticated frameworks and tools.
VMblog: How can developers and AppSec teams work together without slowing releases?
DeStefano: Most mobile app development teams today are under extreme time-to-market pressure. To keep pace, security testing must be built into the development workflow, not bolted on at the end. Continuous, automated mobile app scanning within the CI/CD pipeline helps developers fix issues early in the mobile app lifecycle – when it’s easier and less costly to contextually resolve them. This makes security a more seamless part of the development process rather than a last minute blocker.
In addition to automated mobile app testing, protection and monitoring capabilities give security and development teams collaborative visibility into what happens post-release. This can help with situations where teams need to adjust protections in response to real-time threat telemetry. It can also inform how mobile apps are efficiently maintained in version updates throughout its lifecycle.
VMblog: How should security teams rethink trust boundaries between mobile apps, APIs, and backend systems?
DeStefano: That mobile API security gap is really the place where trust gets exploited in a lot of cases. Even when a requestappears normal or it comes through the expected mobile app and API flow, security teams shouldn’t assume it’s trustworthy. In many real world attacks, the request itself may look valid. The endpoint is correct, the user may be authenticated, and the transaction may follow the expected format. The challenge, however, is tying that request back to the underlying conditions of the app and runtime environment.
To enforce trust-based mobile API security, app attestation can ensure that all interactions with the API come from a genuine, uncompromised mobile app. Requests from untrusted sources–such as bots or malicious clone apps–are all blocked. App attestation effectively binds the app, device, and back-end trust boundaries together.
VMblog: How do organizations move from detecting mobile threats to actually enforcing trust at the point of access?
DeStefano: Perfect way to wrap things up. It’s obviously not very useful to know that a mobile app may be tampered with, instrumented, automated, or running in a risky environment after the fact. Those signals all need to be available before the app is allowed to interact with protected services.
Organizations can move beyond detection by making mobile integrity part of the access decision itself. Validating the app’s integrity before or during sensitive API access helps organizations ensure that only trusted app instances are allowed to perform trusted actions.
And it’s this very same function that can turn mobile threat detection from passive visibility into an active control point.
##
