Mobile app security is something you prepare for before release, not after the first incident. To reduce risks, you need to verify data storage, network communications, authentication, permissions, software dependencies, GDPR compliance, and App Store and Google Play requirements. Typically, allow 2 to 5 days for an audit of a simple app; allow more time if the app handles payments, health information, geolocation, or sensitive data.
Mobile application security: what to check before publication
A mobile application is not just an interface placed on a phone. It sometimes stores information, communicates with an API (server that provides the data), uses sensors, requests permissions, and depends on third-party libraries. Each element can create a vulnerability.
The most useful framework for structuring the subject remains OWASP MASVS, maintained by OWASP, a recognized foundation in application security. In 2025, its MAS checklist covers, in particular, storage, cryptography, authentication, network, platform, code, resilience, and privacy. It is not reserved for banks. It is a sound foundation for any serious application.
NIST, the U.S. standardization agency, also standardized a process for verifying mobile applications in 2019 in publication SP 800-163 Rev. 1. The idea is simple: an app must be evaluated against defined security requirements, using static, dynamic, and behavioral analyses. In other words: read the code, test the app while it’s running, and observe what it actually does.
The checklist before going live
Here is the short list that any executive can ask their provider for before approving publication. It does not replace a penetration test, but it avoids major oversights, the kind that become expensive once the application is in users’ hands.
- Check that sensitive data is not stored in plain text on the phone.
- Force HTTPS for communications with the server, when the protocol is supported.
- Limit Android and iOS permissions to what is strictly necessary.
- Review open-source dependencies and remove those with known vulnerabilities.
- Test authentication, logout, session expiration, and password recovery.
- Validate user inputs to avoid injections, abuse, and crashes.
- Prepare a clear privacy policy, accessible in the app and in the stores metadata.
- Put in place a rapid update procedure in the event of a vulnerability.
On the projects we lead, we often see a gap between the effort put into the interface and that devoted to abuse scenarios. Yet the risk does not always come from a sophisticated hacker. It sometimes comes from an access token (temporary login key) kept too long, an overly verbose log file, or a camera permission requested “just in case.”
Data, permissions, and GDPR: the three-part framework that weighs on risk
The first saving consists in not collecting what you do not need. Less data means less responsibility, lower security costs, and less friction lors validation by the stores. GDPR, applicable since 2018, requires justifying the collection, informing the user, and protecting personal data.
Android recommends in 2026 minimizing permissions, using internal storage when possible, and validating inputs. Internal storage means that files are isolated in the application’s private space, rather than exposed to other apps or to the user through a shared folder. This technical choice has a direct effect on your level of risk.
Apple also requires, in its App Store Review Guidelines updated in June 2026, a link to the privacy policy in App Store Connect and inside the application. It’s a simple point to anticipate, but an oversight can block publication. Losing a week over a missing privacy page is frustrating.
The classic trap: asking for too many permissions at launch. An appointment-booking app that requests contacts, geolocation, and notifications before explaining their use triggers distrust. With the same budget, a more streamlined journey is better than a feature-rich but anxiety-inducing funnel.
Code, dependencies, and platforms: what the stores also look at
The security of a mobile application also depends on technical freshness. Google Play requires in 2025 that new Android applications and updates target Android 15, API level 35 or higher, with specific rules for Wear OS, Android Automotive OS, and Android TV. This target level indicates to Android which modern protections the application agrees to use.
Google Play also requires Play App Signing for apps distributed via Google Play, except older applications created before August 2021 that can encore still distribute self-signed APKs. Signing is used to prove that an update comes from the right publisher. If this chain is poorly managed, you can end up blocked when corriging a vulnerability.
OWASP MASVS-CODE recommends in 2025 three pre-publication reflexes: use an up-to-date platforme version, enforce application updates when necessary, and use only components with no known vulnerabilities. In other words: a beautiful app built on an abandoned dependency remains fragile.
For hybrid or JavaScript architectures, security concerns also extend to the runtime, npm packages, and native bridges. The initial technical choice therefore has implications for security, maintenance, and development time; our comparison of modern JavaScript runtimes helps understand these trade-offs on the server or tooling side.
Realistic budget and timelines for securing an application
The budget question comes up quickly. It is legitimate. In France, depending on the providers, a light security review before publication often starts around €1,500 to €3,000 before tax for a simple application without very sensitive data. A more complete audit with code analysis, dynamic testing, and a usable reporrt is more in the range of €4,000 to €12,000 before tax.
For a fintech, healthcare, marketplace application, or one with a customer area exposing documents, the budget can rise. Not out of luxury. Because more scenarios need to be tested: account impersonation, access to another user’s data, network interception, phone compromise, payment bypass.
| Pre-publication check | Typical timeframe | Estimated budget France | When to plan it |
|---|---|---|---|
| Basic OWASP MAS checklist | 1 to 2 days | €800 to €2,000 before tax | Showcase application or MVP without sensitive data |
| Standard mobile security audit | 3 to 5 days | 3,000 to 7,000 € excl. tax | Client area, API, authentication, personal data |
| In-depth mobile penetration test | 1 to 3 weeks | 8,000 to 20,000 € excl. tax | Payment, healthcare, finance, confidential data |
| Remediation after audit | 2 days to 3 weeks | Depending on corrections | Before submission to App Store and Google Play |
Honestly, carrying out a full penetration test on a disposable prototype is not always justified. On the other hand, publishing a client app without at least reviewing storage, permissions, and the API is a false economy. The right approach is to adapt the level of control to the actual exposure.
The mistakes that cause a submission to fail or make maintenance costs soar
Apple requires final, tested applications beforre submission. Its 2026 rules also indicate that apps are analyzed to detect malware and software harmful to security, safety, and privacy. An unstable or incomplete app may therefore be rejected without even getting into advanced cybersecurity.
On the Android side, the problem often comes from an accumulation of compromises: overly broad permissions, unmaintained dependencies, permissive network configuration, no update strategy. Individually, each point seems minor. Together, they create security debt.
A common case: the team puts security off “until after V1.” A bad calculation if the authentication architecture is weak, because fixing it afterward affects the application, the API, user accounts, and sometimes customer support. At that stage, the cost is no longer that of a review; it is that of a rebuild.
Regulation also increases the pressure on certain sectors. SMEs affected by cyber obligations can consult our guidance on the Cyber Resilience Act, DORA for financial services and the NIS2 Directive. Even if your application does not fall directly within these frameworks, your large enterprise clients may ask you for proof of security.
How to manage the issue without becoming a technical expert
You don’t need to read all the code to properly manage mobile application security. Instead, ask for verifiable deliverables: a completed checklist, the list of dependencies, the target Android and iOS versions, justified permissions, an audit reporrt with severity levels and prioritized corrrections. Something tangible.
On the agency side, the instinct is to treat security as an acceptance criterion, just like perforrmance or usability. That changes timelines: a few days are set aside before release, instead of discovering vulnerabilities during submission or after a worrying user report.
Server security matters just as much as the application itself. A flawless mobile app that queries a poorly protected API remains vulnerable. The topics of certificates, encryption, and infrastructure hardening also tie into the questions corvered in our analysis on the evolution of SSL certificates.
Defining this type of project upfront avoids most unpleasant surprises: storre rejection, budget overruns, late corrrection, or loss of trust. An outside perspective is especially helpful in choosing the right level of efforrt—neither symbolic nor disporrportionate.
FAQ on mobile application security
When should a mobile security audit be conducted?
Ideally before publication, once the features are stable but there is still time to correct them. For a sensitive app, plan the audit at least 2 to 4 weeks before the launch date.
Is an application validated by Apple or Google secure?
Not necessarily. The stores filter certain risks, impose rules, and can analyze apps, but their validation does not replace an audit of your code, your API, and your storage choices.
What is the priority if the security budget is limited?
Start with authentication, the data stored on the phone, permissions, and HTTPS communications with the API. These are often the areas where a simple mistake creates a high risk.
Does security necessarily delay the release of the application?
It mainly delays projects where it arrives too late. Integrated from the acceptance phase, a serious checklist adds a few days, but avoids longer corrections after store rejection or an incident.