Debunking Mobile App Security Misconceptions

The following blog is based on the recent appearance of Guardsquare Product Manager, Joel DeStefano, on the Ship It Weekly podcast with Brian Teller. The full recorded episode is available for listen below. Continue reading for additional insights and highlights from their conversation.

Developers often have preconceived notions about mobile app security, many of which are misleading or untrue. This biased perception can have real world consequences when it comes to protecting applications from real world attacks. In 2025, the average cost of a security breach was $4.4 million, with costs soaring depending on the incident. With incidents holding the potential for such massive negative impact, treating mobile app security as an afterthought is a no-go.

Recently, Joel DeStefano, Product Manager at Guardsquare, sat down with Brian Teller from Teller’s Tech for an interview on the popular podcast Ship It Weekly. Brian and Joel defined mobile app security, examined important considerations for mobile app developers, dispelled common misconceptions on mobile app security, and shared overall best practices.

Misconception #1: Scanning and App Store approval are enough

Google Play and the App Store have different requirements for applications to be made available for download on their platforms. However, they do not have exhaustive security requirements that are sufficient for defending against today’s sophisticated attacks. Meeting the requirements of these app stores can give developers a false sense of security.

To meet app store approval, app developers scan their application for gaps and vulnerabilities prior to release. However, even if issues are found and addressed, the pre-release scanning only applies to the app itself. It doesn’t provide protection for the environment the app is operating in. This means that the app can be exposed to insecure environments, like a user running the app via an emulator or on a jailbroken or rooted device. Essentially, your application isn’t protected from these external threats that persist in the open world. Your application requires protection from real world threats once it is made publicly available. Joel elaborates further:

“Scanning is something you would do before you release the application. That's… your background to make sure that [you] don't have any vulnerabilities, [you] understand third-party dependencies… , and coding practices [are] not insecure or improper…..But then, once you release… those are more point in time type of protections.

Now you've done your due diligence prior to release; when it goes out, you need to still be able to trust that the applications and the users that are connecting to your backend are using a genuine application. It hasn't been compromised. And the integrity of that app and the entire runtime execution is good. That's the only way you could actually…protect yourself. You need to be able to trust it. And that's…the gap and the challenge with a mobile app [as] opposed to a backend or a cloud service… visibility is lost.

You don't control that environment. You don't know if it's going into a malware environment. You don't know if it's going into the hands of attackers. You don't know what they're doing with it. That's the real, fundamental difference.”

Misconception #2: We don't have sensitive data, so we're not a target

Another misconception is that since a mobile app doesn’t store sensitive information, it doesn’t require security protections. But this represents a disconnect between the mindset of a developer and that of an attacker. An attacker may not necessarily be looking for what a developer thinks they are looking for. There are portions of the application that open up avenues to a treasure trove for attackers to plunder. Joel lays out the disconnect between developer and attacker methodology:

“I have come across a lot of people who will say, ‘well, we don't have anything sensitive in our app. We do all our protections on the back end with our APIs.’ And that may be true. They may not have a lot of sensitive information. What they don't understand, generally, is that an attacker doesn't necessarily need to find the same things that you might be worried about or think are a concern.

I would say almost any app that has business critical workflows, transactions, logins, [or] deals with money - something can be learned from decompiling that application. You don't know what they're figuring out from that application. That's why you proactively [protect] that app with code hardening. We call it obfuscation, basically scrambling up names and things so that [attackers] can't reverse it and quickly figure out the business logic or what's going on with the application.

In addition, there are runtime checks. Those are basically checks that can be injected into [an] application that go beyond just reverse engineering. Runtime checks detect whether or not something about that environment or that runtime execution at that moment is not right. There are certain techniques, frameworks, and utilities that attackers will use to change a value, bypass something in the application. Those [techniques] need to be [protected against] because they are not necessarily protected by code hardening. [Anti-hooking protections] help prevent that from happening because it's harder to figure out where the attacker might want to look.

There are a lot of threats and risks that are in that mobile application beyond the ‘we have no sensitive keys in there’ or something like that.”

Misconception #3 Android is riskier than iOS because it's open source

One myth that has been around from what seems like the dawn of mobile app development is that iOS apps are more secure than Android applications. The reason for this misconception is the nature of each platform. Android operates an open-source system that introduces significantly more variability than the closed source system of iOS. While, on the surface, this gives the perception that Android apps operate in an inherently riskier environment, Joel explains to Brian why this is not the case:

“The same type of attacks can be carried out on both platforms. The same risks are on both platforms. The ecosystem in Android is a little bit different because it's a little less controlled as far as the number of devices that are floating around in the world, the number of operating systems that are still in support. And it is an open-source model, but that is a misconception as well. There's a misconception out there that because iOS is closed source and Android is open source that all the problems happen [on Android apps].”

What layered defense actually looks like

Employing a multi-layered, defense-in-depth strategy creates a fortress of defense within your application from outside threats. Unlike wrappers, which are a single click implementation, single point of failure solution, building multiple layers of defense within your application provides reinforcements against the onslaught of today’s most sophisticated attacks. The key is to make security an integral part of app development by weaving into the fabric of the SDLC whenever applicable, as Joel describes in depth:

“Testing is the scanning aspect, where we look for the vulnerabilities, insecure coding practices, and improper implementations. Hardening is a core product [component], which is a compiler-based approach of adding protections into that application. So we'll take the output IPA or APK, depending upon the platform, decompile that, add the code hardening and obfuscation to make that decompiled code look like gibberish to somebody. [We] also inject… what we refer to as runtime checks.

So, for example, is this device rooted or is someone attaching a hooking framework? Has somebody gotten around the actual certificate? Is there malware on the device that's trying to abuse accessibility services or using overlay or a screen reader to scrape information? That's the hardening aspect.

The monitoring aspect is another important part of this broader picture, which is… where that whole trust model, that lack of visibility comes to the forefront. Even if you are protected, you still want to monitor what's going on because things shift. You might see, all of a sudden, evidence of certain behavior in a certain part of the world. So maybe you want to pause for a second and ponder: do we want to change our configuration, release a new application, maybe improve some of the protections here? What exactly is going on? It's not [as simple as] adding your protections and being done. You should… be monitoring and essentially allow yourself the flexibility to change your posture as needed.”

Where to start: The top 3-5 things to get started

The hardest part is getting started. It’s best to begin by asking the right questions and putting yourself in the mindset of an attacker. What are they looking for in our application that is valuable to them? Then figure out how to start incorporating protections based on your existing workflows. Joel breaks down what this approach looks like:

“I would say not to get overwhelmed. I would take a step back and start asking some really basic questions. What matters to us? How is this app interacting with our backend? What could possibly hurt us? Start brainstorming there.

Then, consider a structured programmatic approach to layering in your security so that it becomes part of your routine. It can't be an after-the-fact type of thing. You should be thinking about it up front, during, and obviously at release and after release. So it's a bit of a mindset. If you treat it as a checklist type of thing at the very tail end, that’s where you get yourself into trouble because you either didn't protect the app well enough or you did it in a way that might risk some of your priorities or requirements. It's a mindset that security is top of mind, from all facets, all the time.

If security is part of your daily routine, just like exercising, you make it a habit, so you're going to do it all the time. And if you're considering security as being important, it's an… understanding that this is part of life. It's the right way to go about it because you'd rather not be in the news because someone made an example of your application or some of your users were victims of fraud or your organization was part of some sort of criminal misuse situation, which does happen.”

For the full conversation, including insights on balancing app protections with CI/CD pipelines, you can listen to the recorded episode via the link at the top of this blog.

If you’re interested in learning more about how Guardsquare can assist you in more mobile app security needs, contact us today.