Imagine: a banking app passes a penetration test, all checks are green, and a month later it turns out that access tokens were stored in plaintext in SharedPreferences. Or another case: developers enabled SSL pinning, but only for the main domain, while the file upload API remained unprotected. Such stories are not rare. Mobile app security seems simple until you encounter a real device where everything works differently than on an emulator. For a deeper dive into this topic, see Embedded Linux & IoT.
In this article, we'll break down why Mobile Security is a separate discipline, not just "another section of web security." We'll show by example how a practitioner searches for vulnerabilities, which failure modes occur most often, and who really needs to master this field — and for whom it would be a waste of time.
Why mobile security is not "web, but smaller"
A mobile app is not a miniature website. The threat landscape is different: code is stored on a device that the user can fully control (root, jailbreak), traffic can be intercepted via a proxy, and reverse engineering allows recovering logic even from an obfuscated binary. In web, you don't give server-side code to the client, but in a mobile app you do — and it must be protected. For a deeper dive into this topic, see Platform Engineering.
The key difference is the trust model. In web, the server trusts only itself, while in a mobile app the client and server constantly exchange data, and the client can be compromised. Therefore, all checks performed on the device (e.g., signature verification or root detection) can be bypassed using tools like Frida. This gives rise to a whole class of attacks not found in web: on-the-fly code substitution, traffic interception and modification, memory dumps.
Another important aspect is platform fragmentation. iOS and Android have different security mechanisms: on iOS it's code signing and sandboxing, on Android — permissions, SELinux, and Verified Boot. Tools also differ: for Android, APKTool, MobSF, Drozer are used; for iOS — class-dump, Cycript, Frida. A specialist must be able to work with both platforms or at least understand their differences.
What vulnerability hunting actually looks like: a walkthrough of one task
Suppose we have an Android app for an online store. The task is to check whether an attacker can access the API on behalf of another user. We start with traffic analysis: set up Burp Suite as a proxy on the emulator, install the Burp certificate into the system store (possible on an emulator, but not on a real device without root). Launch the app and see that traffic flows, but some requests are not decrypted — the app uses SSL pinning.
The first step is to bypass pinning. For this, we use Frida and a script that intercepts certificate verification functions. For example, for OkHttp3 it would be CertificatePinner.check(). Load the script via frida -U -f com.example.app -l bypass.js. If done correctly, traffic starts passing through the proxy in plaintext. But mistakes are common here: forgetting that some libraries (e.g., TrustKit) may use native checks, requiring a different approach — patching the APK via apktool and rebuilding.
After bypassing pinning, we analyze requests. We see that authorization occurs via a token in the Authorization header. We try modifying the request body: for example, replacing userId in the request with another. If the API does not verify that the token belongs to this userId, it's an IDOR (Insecure Direct Object Reference), one of the vulnerabilities from the OWASP Mobile Top 10. In a real case, this led to any user being able to read others' orders just by knowing their identifier.
Next, we check data storage. Using MobSF, we perform static analysis of the APK: check whether passwords or tokens are stored in plaintext in SharedPreferences or a local SQLite database. Often developers use EncryptedSharedPreferences, but the encryption key may be static or derived from a simple password. If we find a token in plaintext, it's a critical vulnerability.
What will go wrong if done otherwise? If you skip the pinning bypass step and go straight to static analysis, you may miss what data is sent to the API and overlook logical vulnerabilities. If you don't test the API for IDOR, you may give a false conclusion about security. Finally, if you test only on an emulator, you may miss protection that only triggers on a real device (e.g., root detection).
Where protection breaks: typical failure modes
In mobile security, there are several scenarios where even well-designed mechanisms stop working. Let's look at the most common.
1. SSL pinning that is easy to bypass
Certificate pinning is a popular measure, but many implement it only for the main domain, forgetting about CDN or file upload APIs. Or they use outdated libraries with known bugs. How to notice in advance: route traffic through a proxy and see which domains remain unencrypted. If you see that requests to api.example.com go through the proxy without errors, but those to cdn.example.com do not, then pinning is incomplete. What to do: implement pinning at the network stack level (e.g., via Network Security Config on Android) for all domains, including third-party SDKs.
2. Obfuscation that doesn't hinder reverse engineering
Developers enable ProGuard or R8, but forget that class and method names can still be recovered from strings, resources, or API calls. Frida allows intercepting methods by signature even if names are obfuscated. How to notice: try to find strings containing keys or URLs in the decompiled code — they often remain in plaintext. What to do: use stronger obfuscation (e.g., DexGuard) and avoid storing secrets in code.
3. Root checks bypassed with a single script
Many apps check for root or jailbreak, but do so via simple file checks (/system/app/Superuser.apk). Frida allows replacing the result of any function returning a boolean. How to notice: if the app crashes or behaves strangely on a rooted device but does not block core functions, the check is ineffective. What to do: use multiple layers of verification (SafetyNet Attestation, APK integrity check) and do not rely solely on client-side checks.
4. API security that ends at the client
Developers often think that if the app has a permission check, the API is protected. But the API can be called directly, bypassing the app. For example, if the app checks that the user is an admin and only then shows the delete button, but the API does not check permissions when the delete method is called, that's a vulnerability. How to notice: analyze requests and try to perform actions unavailable in the UI. What to do: always duplicate checks on the server.
Learning paths: self-study, courses, practice
You can master mobile security in different ways. The most accessible path is self-study: read the OWASP Mobile Security Testing Guide, watch conference recordings, complete labs on Hack The Box or PentesterLab. Pros: free or cheap, flexible schedule. Cons: no feedback, easy to miss important details, mistakes in a pentest can lead to false conclusions.
The second path is courses. They provide structure, practical assignments, and error analysis. For example, the course "Mobile Security — Securing Mobile Apps (iOS and Android)" on asibiont.com includes working with MobSF, Frida, Objection, Burp Suite, and other tools. Learning is built on personalized lessons that adapt to the student's level. But courses require time and money, and not all provide deep practice on real devices. For a deeper dive into this topic, see Machine Learning & Deep Learning.
The third path is practice at a company or freelance. The most effective, but requires initial skills and is often unavailable to beginners. You can start with bug bounty: search for vulnerabilities in mobile apps on platforms like HackerOne. This gives real experience and feedback, but competition is high.
Trade-off: self-study is cheaper but slower and risks gaps. Courses are faster and more structured but cost money. Practice gives the best results but requires basic preparation.
Who this path suits and who it doesn't
Mobile Security is not for everyone. Here are criteria to help you decide.
It suits you if you are:
- A mobile app developer (iOS or Android) and want to understand how to protect your code.
- An information security specialist looking to expand expertise to mobile platforms.
- A tester who wants to move into pentesting and is looking for a specialization.
- A technical student with basic knowledge of OS and networks.
It does not suit you if you:
- Are a complete beginner in IT and unfamiliar with the basics of Linux, networks, and programming. Without this, it will be too difficult.
- Expect the course to make you an expert in a week. Mobile security requires practice and time.
- Are not ready to work with real devices and tools that may lead to device bricking (e.g., root).
If you fall into the first category, start with the basics: study the OWASP Mobile Top 10, try labs on PortSwigger (they exist for mobile apps too). Then move on to practice with Frida and MobSF.
The course "Mobile Security — Securing Mobile Apps (iOS and Android)" provides a structured path: from traffic analysis to reverse engineering and API protection. It will be useful for those who want to systematize knowledge and get feedback on practical assignments. Details and enrollment — on the course page: Mobile Security — Securing Mobile Apps (iOS and Android).
If you prefer self-study, start with OWASP MSTG and practice on Hack The Box — but be prepared that the path will take more time and require self-discipline.