Data theft, malware, hacked APIs... mobile app usage is skyrocketing, and so are attacks. Are your mobile apps truly secure? Beyond simple encryption, how can you guarantee true security without compromising the user experience? How do you manage secure storage or hardening Client/server? What about your tests? Are they aligned with current standards? Discover the essential practices and tools for coding secure, high-performance apps that truly inspire confidence.
First, let's set the scene with a few figures. In 2024, Akamai recorded no fewer than 311 billion attacks. The most striking thing? Nearly half of them directly target APIs that serve as backdoors. This is the first major challenge for developers.
But these are not the only attacks on mobile devices, far from it! In 2025, the pressure intensifies. Attacks on Android smartphones have surged. 29 % in the first half of 2025 compared to the previous year, according to Kaspersky.
Cybercriminals don't look far: they target what pays off immediately. OTPs (one-time passwords) to bypass two-factor authentication, wallets to siphon off digital assets and, of course, bank details, which remain their holy grail.
Android is the primary target, but iOS is no longer the impenetrable sanctuary it was thought to be a few years ago.
The security of mobile apps is therefore becoming a priority.
The threat in figures: the explosion in attack surface
| Target of attack | Statistics (2025) | Impact for the developer |
|---|---|---|
| Application attacks | 83 % organisations attacked in January 2025 (65 % at 2024) (Digital.ai) | Prioritise continuous testing, customer hardening |
| API attacks | > 40,000 incidents at S1 2025 (Thales) | Check each endpoint + anti-abuse (detection/blocking of abuse, bots, fraud) |
| AI/API vulnerabilities | + 1025 % from AI-CVE in 2024 of which 98.9 % related to APIs (Wallarm) | Test inputs/outputs and AAA controls |
| Android threats |
+ 29 % attacks S1 2025 vs S1 2024 (Kaspersky) |
Impose anti-tamper (prevent modifications to the app) and environment detection |
| Average cost of a breach | 4.88 M$ (IBM) | Inertia cost more expensive than the tools |
Your roadmap: 3 pillars for mobile defence
Faced with this tidal wave, checklists scribbled on the corner of a table are no longer enough. You need a solid defence architecture based on three complementary pillars that reinforce each other.
1er pillar: the reference framework that structures your approach
Before you even write a line of code, you need some reference points. That's exactly what we offer you. OWASP Mobile Top 10 in its 2024 version.
This reference guide identifies the ten major risks facing your mobile applications, from unsecured storage to weak cryptography and code injections. Each risk is documented, explained and contextualised. And the OWASP Mobile Top 10 offers solutions to each problem.
Furthermore, this framework serves as a basis for discussion with any security team.
But a list of dangers is not enough. These abstract threats must be translated into concrete actions, and that is where the MASVS v2 (Mobile Application Security Verification Standard).
This standard acts as a universal translator between the world of risks and that of developers.
Let's take a concrete example: the risk of «unsecure data storage» becomes a specific and verifiable requirement in MASVS: «the application must not store any secrets in plain text in the preferences». Gone is the artistic vagueness, replaced by clearly defined criteria.
Follow the MASTG guide
To validate that you meet these requirements, you can then refer to the MASTG, the Mobile Application Security Testing Guide, which provides you with practical and reproducible test scenarios.
This OWASP-MASVS-MASTG trilogy forms the backbone of your security quality assurance.
Hélène, Engineering Manager in a B2B organisation, explains how her team transformed the MASVS into a product backlog:
«When we decided to take the MASVS Seriously, we've stopped making grand statements and moved on to actual differences. We had 17 red dots on the part. RESILIENCE : anti-debug, anti-hook, log leakage... We set up a single board shared between developers, QA and security, and planned two dedicated sprints. For each user story, a MASTG test evidence was required. The result: in three weeks, no more easy bypasses, and a team aligned on the same reading grid. Today, there is no longer any debate: if it is serious, we measurement. »
2nd pillar: active client-side defence
Your application runs on a device that you do not control. That is a fact. The user may have rooted his Android, jailbroken their iPhone, or worse still, installed malware that listens to everything that passes through it. The fundamental question then becomes: how can you be sure that you are really talking to YOUR application and that the device is secure?
The answer lies in the’physical evidence, this ability to link your application to Hardware Security Module (HSM) of the device.
On Android, this means migrating without delay to Play Integrity (which replaced SafetyNet). Play Integrity not only verifies the integrity of the binary, it also certifies the actual state of the environment: presence of root, malware detection, signs of tampering. Your code must be ruthless: block all execution if the status MEETS_BASIC_INTEGRITY fail. No half measures, no degraded mode that would let a determined attacker through.
On iOS, the reflex is called App Certificate. This service offered by Apple cryptographically links your application to your server. Specifically, it provides a token that your back end must validate with each sensitive call. This proves that it is indeed YOUR legitimate application sending the request, and not a modified version or malicious clone.
Keep secrets safe
As for the secrets of the application, they must never leave their physical safe., Android Keystore and iOS Keychain. They do not simply encrypt your keys and tokens, they bind them to the device's hardware. This binding makes extraction nearly impossible without advanced physical compromise, which completely changes the equation for the attacker. Therefore, never, ever store a secret in plain text in your binary or in shared preferences.
Maëlys, Android lead in an application retail, demonstrates the immediate impact of these measures:
«We suspected app clones who were calling our sensitive endpoints. The day we deployed App Certificate iOS side and Play Integrity On the Android side, we've changed the rules of the game. The back end now refuses any critical appeal without valid certification, full stop. In two sprints, the fraud attempts visible in our logs were divided by three. From the user's perspective, nothing has changed: no added friction, just a radio silence scripts that were brute-forcing our APIs.
3e pillar: the armoured API
The API is where mobile security is won or lost. A stolen access token is literally the keys to the kingdom, giving full access to the user's account and all their data.
If you are still using the implicit OAuth 2.0 flow, you are giving attackers an opportunity. Switching to OAuth 2.1 with PKCE mandatory is not a simple cosmetic update, it is the closing of a gaping hole. As the OAuth 2.1 specification remains an Internet Draft, the key thing is to apply these measures now.
PKCE (Proof Key for Code Exchange) ensures that even if an attacker intercepts the authorisation code during redirection, they cannot exchange it for an access token.
This is already a solid first step, but it only solves part of the problem.
What happens if the final access token is stolen afterwards? Via malware, a leak in the logs, or XSS? This is where DPoP (Demonstration of Proof-of-Possession) comes into play. This standardised mechanism, which is easier to implement than mTLS on mobile devices, is a game changer.
In practical terms, with DPoP:
- The mobile client generates a local key pair.
- He signs each request API with its private key (via a dedicated DPoP header).
- The server validates the signature and verifies that the access token is linked to this public key.
Result: a stolen access token becomes useless. An attacker who does not possess the private signature key is left with a simple string of characters with no exploitable value. It is elegant, effective, and closes a door that many applications leave wide open.
Finally, never neglect the transport layer. Require TLS 1.2 minimum and prefer TLS 1.3, Banish weak encryption suites (following the recommendations of ANSSI or Mozilla). Use HSTS (HTTP Strict Transport Security) for your front end web only to prevent attacks by falling back to unsecured connections. For native apps, prioritise the certificate pinning (Android Network Security Configuration, iOS ATS) and a planned rotation of keys. These measures are completely invisible to the end user... and they close entire doors to opportunistic attackers.
Clara, an SRE in an HR SaaS company, sums up the impact well:
«We have normalised TLS 1.3/HSTS throughout the park. For customers, nothing has changed. For us, a lot has changed.’noise alerts has disappeared and the external scans are finally clean. Frankly, this is one of the few measures at virtually no cost and high impact that can be deployed quickly.»
The two blind spots that can change everything
Beyond the three pillars, two grey areas often remain in mobile security strategies. These are blind spots that, if overlooked, can undo all your efforts.
The first blind spot: your supply chain, that invisible minefield
Let's be honest: that analytics SDK you integrated two years ago, that advertising module that seemed so useful, can turn into a Trojan horse overnight. A vulnerability discovered in a third-party dependency, an SDK acquired by a company that is less concerned about security, and your entire application becomes porous.
The first step is to know exactly what you are taking with you. To do this, systematically generate an SBOM, a Software Bill of Materials, in CycloneDX format with each build.
This comprehensive inventory lists all your direct and transitive dependencies, creating an accurate map of your attack surface.
But an inventory is not enough; it must be analysed. This is where SCA (Software Composition Analysis) tools come in, scanning your SBOM to detect known vulnerabilities. Above all, question each dependency: does this advertising SDK really need access to the network AND the user's contacts? Document these choices and ruthlessly cut off unnecessary access.
Louis, AppSec manager in a media company, discovered an unexpected benefit of this approach:
«When we released our first clean CycloneDX SBOM, we thought we were in the clear. However, the SCA scan revealed a public SDK with outrageous permissions and a fresh CVE. We removed the SDK, implemented a dependency approval process, and added a scope review to each release. An unexpected benefit was that network consumption decreased, as did start-up time. We didn't expect the performance and security gains.»
The second blind spot: the absence of DevSecOps, or how to put off problems until tomorrow
Security tested at the end of the cycle guarantees that critical issues will be discovered when it is too late to correct them properly. Security must therefore become a build requirement.
To do this, automate your defence cycle. Run static analysis (SAST) and dependency analysis (SCA) at each commit. Integrate tools such as Semgrep or SonarQube for the code, Syft (SBOM generation) and Grype (vulnerability scan). The objective? Break the build if a secret is hard-coded or if a critical vulnerability is found. No tolerance, no «we'll see later».
Then move on to the binary itself. Integrate MobSF, the Mobile Security Framework, into your CI pipeline to audit the generated APK or IPA. If the basic MASVS configurations are not met, the build fails.
Add API tests : DPoP checks (nonce/jti/iat/htu/htm), abuse/bot detection, and rotation of refresh tokens with reuse detection.
Finally, leverage your security tests. Use Frida or Objection to automate checks of’anti-tampering. If your defences against root/jailbreak or the SSL pinning do not react as expected, the build fails. This rigour may seem brutal at first, but it radically transforms the quality of what you deliver.
Romain, DevSecOps at an EdTech company, talks about the cultural shift:
«The first time we broke the build for a MobSF regression, it was unpopular. Two days later, no one was arguing anymore: security quick wins were released before production, not after. We added a weekly control report, which became a product acceptance criterion. As a bonus, stress in MEP melted away: we know what we're delivering.»
Your action plan: where to begin?
Faced with this list of measures, paralysis looms. Where to start? How to prioritise? Here is a pragmatic approach, divided into three phases of two weeks each.
Week 1-2: Map out the existing situation
- Put your app through its paces with the MASVS v2
- Identify your 5 critical gaps (those that expose your users the most)
- Generate your first SBOM CycloneDX with Syft and scan it with Grype
Week 3-4: Implement the foundations
- Customer : Play Integrity (Android) + App Attest (iOS)
- API : PKCE + DPoP on your endpoints sensitive (those that handle critical data or financial transactions)
- Transportation : TLS 1.2 minimum/1.3 preferred + certificate pinning (Android Network Security Config / iOS ATS) (HSTS reserved for your web front ends)
Week 5-6: Industrialise in the CI/CD pipeline
- Integrate SAST/SCA with the rule: any critical vulnerability breaks the build
- Add MobSF for auditing your binaries
- Automate a test Frida on your main countermeasures + DPoP API tests
The open bar is closed... permanently!
The era of mobile being considered a «simple customer» is over. It is now a endpoint Critical. The figures for 2025 prove it unequivocally: attackers are having a field day.
Physical authentication, enhanced authentication, and strict identity verification are no longer reserved for banking applications.
Security is no longer a feature you add if the budget allows. It is the very foundation of the trust you build with your users. Don't wait for the catastrophic audit report or data breach that will cost you millions. Your new mantra should be: « If it's not secure, it doesn't go into production. »
Your job is no longer just to deliver code that works. It's to deliver confidence. Your next commit will be your first line of defence. Make it count.
