Mobile App Security in 2026: Risks, OWASP Standards, Testing and Costs

Most of the apps people install handle something worth stealing: a login, a payment token, health data, a home address, or simply a way into a company’s backend. That is why mobile app security has moved from a last-minute checklist to something that shapes how an app is specified, built and released. If your app is on the App Store or Google Play, or about to be, assume someone will download it, unpack it and look at what it gives away, exactly as a security tester would.

This guide brings cyber security for mobile apps up to date for 2026. It covers the risks in the current OWASP Mobile Top 10, the OWASP MASVS and MASTG standards that testers work from, the iOS and Android platform changes that affect security, the UK and EU rules worth knowing, and what a mobile app security test costs in the UK.

Contents

1. What mobile app security covers today
2. The OWASP Mobile Top 10 risks (2024 edition)
3. OWASP MASVS and MASTG: the standard for cyber security for mobile apps
4. iOS and Android changes that affect app security
5. Mobile app security best practices that still hold
6. How to test mobile app security
7. UK and EU rules that apply to your app
8. How much does a mobile app security test cost in the UK?
9. How Yeeply can help

What mobile app security covers today

The app itself is only one piece. A realistic assessment looks at four layers: what the app stores on the device, how it talks to the network, the APIs and backend it depends on, and the third-party SDKs and libraries packaged inside it. Many of the serious findings in mobile tests turn out to be backend findings, such as an API that trusts whatever user ID the app sends, or a session token that never expires.

The risk is real for UK companies. The government’s Cyber Security Breaches Survey 2025/2026 found that 43% of UK businesses identified a breach or attack in the previous 12 months, with phishing reported by 38%. Only 34% have a policy to apply software security updates within 14 days. That figure matters for apps too: a vulnerable library in your app or your API stays exploitable until someone ships the fix and users install it.

The OWASP Mobile Top 10 risks (2024 edition)

The OWASP Mobile Top 10 is the reference list of the most common and damaging risks in mobile apps. The current edition is the 2024 final release, which replaced the 2016 list, and as of October 2026 OWASP has not published a newer one. The order changed a lot: credential handling and the supply chain now sit at the top.

Risk	What it usually looks like in a real app
M1: Improper Credential Usage	API keys or passwords hardcoded in the app, credentials stored in plain text
M2: Inadequate Supply Chain Security	Third-party SDKs with known flaws or excessive permissions, a compromised build pipeline
M3: Insecure Authentication/Authorization	Backend endpoints that trust the client, no check on who can read which record
M4: Insufficient Input/Output Validation	Injection through deep links, WebViews or API parameters
M5: Insecure Communication	Traffic without TLS, invalid certificates accepted, sensitive data in URLs
M6: Inadequate Privacy Controls	More personal data collected or logged than needed, data leaking into analytics tools
M7: Insufficient Binary Protections	An app that is easy to reverse engineer or modify, exposing secrets and business logic
M8: Security Misconfiguration	Debug settings in production, exported Android components, permissive backup settings
M9: Insecure Data Storage	Tokens or personal data in shared preferences, plist files, logs or caches
M10: Insufficient Cryptography	Weak or home-made algorithms, hardcoded keys, poor key management

Two of these deserve a closer look. M2 reflects how apps are really built: a typical app ships with analytics, crash reporting, payments and advertising SDKs, and each one runs with your app’s permissions. M6 links security with data protection law, which is where many UK businesses get caught out when an SDK sends more data than anyone realised.

OWASP MASVS and MASTG: the standard for cyber security for mobile apps

The Top 10 tells you what tends to go wrong. The OWASP Mobile Application Security project tells you how to check it, and it has three parts:

• MASVS (Mobile Application Security Verification Standard) sets the requirements. Version 2.1.0, released in January 2024, groups the controls into eight categories: STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE and PRIVACY. PRIVACY was the main addition in that version.
• MASTG (Mobile Application Security Testing Guide) explains how to test each control on Android and iOS, with techniques, tools and runnable demos. Version 2.0.0, published on 30 June 2026, completed a multi-year rewrite into individual tests that can be referenced one by one.
• MASWE (Mobile Application Security Weakness Enumeration) is a catalogue of specific weaknesses that links each MASVS control to the MASTG tests that cover it.

In practice this gives you a shared language with whoever tests your app. Instead of asking for “a mobile pentest”, you can ask for an assessment against MASVS with the testing profile that fits: a baseline for most apps, a stricter level for apps that handle payments or health data, and resilience testing (anti-tampering, anti-debugging, root and jailbreak detection) when reverse engineering is a business risk, as in banking or gaming. With findings mapped to MASVS controls, you can compare reports between providers and releases.

iOS and Android changes that affect app security

Both platforms have tightened their rules over the last two years. These are the changes most likely to affect a release plan in 2026.

Apple (iOS and iPadOS)

• Privacy manifests. Since 1 May 2024, apps and the third-party SDKs inside them must declare an approved reason for using certain “required reason” APIs. An app that bundles an SDK without a valid privacy manifest can be rejected.
• New toolchain. Since 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using the iOS 26 SDK, so an old toolchain or an abandoned dependency is no longer an option.
• Minimum target. From 9 September 2026, iOS and iPadOS apps uploaded to App Store Connect must target iOS 13 or later (all dates from Apple’s upcoming requirements page).

Google (Android and Google Play)

• Target API level. New apps and updates on Google Play must target Android 16 (API level 36) since 31 August 2026, with extensions available until 1 November 2026. Each new level brings stricter defaults for permissions, background work and intents.
• Play Integrity instead of SafetyNet. The SafetyNet Attestation API was fully turned down in January 2025. Apps that check whether they run on a genuine device and an unmodified build now need the Play Integrity API.
• Developer verification. From 30 September 2026, apps installed on certified Android devices in Brazil, Indonesia, Singapore and Thailand must come from verified developers, with a global rollout planned for 2027.

None of this replaces a security review, but it does set deadlines. An app that hasn’t been touched since 2023 probably can’t ship an update today without rebuilding its toolchain, and that rebuild is a good moment to pay off security debt as well.

Mobile app security best practices that still hold

The basics from earlier versions of this guide still apply. What has changed is the level of detail testers now expect, so here they are mapped to the risks above.

Authentication decided on the server (M1, M3)

Multi-factor authentication and biometrics are standard now, but biometrics only unlock something stored on the device. The server still has to decide who can do what. Use short-lived access tokens with refresh tokens, revoke sessions on logout and password change, and check authorisation on every API call as well as at login.

No secrets inside the app (M1, M7)

Anything in the app package can be extracted, obfuscated or not. API keys with real privileges, signing keys and backend credentials belong on the server. Obfuscation slows attackers down and makes tampering harder, which is worth having in high-risk apps, but it does not keep a secret safe.

Data stored with the platform’s protection (M9, M10)

Keep keys and tokens in the iOS Keychain and the Android Keystore, encrypt local databases that hold personal data, and keep sensitive data out of logs, screenshots, the clipboard and device backups. Use current algorithms from the platform’s own crypto libraries rather than custom code.

Secure communication (M5)

Use TLS for every connection and leave certificate validation at the platform default unless there is a good reason to change it. Certificate pinning helps in high-risk apps, but it needs a rotation plan, or a routine certificate change can lock users out of your app.

Third-party SDKs under control (M2, M6)

Keep an inventory of every library and SDK (a software bill of materials), know what data each one collects, update them on a schedule and remove the ones you no longer use. The same inventory feeds the privacy manifest on iOS and the Data safety section on Google Play.

Backend and API protection (M3, M4, M8)

Validate input on the server, rate-limit login and password reset endpoints, and put the API behind a web application firewall where it makes sense. The OWASP Top 10 for web applications applies to your backend as much as to any website.

A plan for when something goes wrong

Have a way to force users onto a fixed version when a critical flaw appears, a published contact point for people who want to report a vulnerability, and a procedure for telling users and the ICO if personal data is affected. The UK’s code of practice for app developers, covered below, asks for exactly these things.

How to test mobile app security

Testing works best in layers:

• Static analysis (SAST) scans the source code in your CI pipeline on every change. It is cheap and catches hardcoded secrets and insecure API use early.
• Automated mobile analysis with tools such as the open-source MobSF examines the compiled app (APK or IPA). It is useful between releases, but its findings need someone to separate real issues from false positives.
• Dynamic and API testing (DAST) attacks the running backend the way an outsider would.
• A manual mobile penetration test works through the MASVS controls with tools such as Frida to bypass client-side checks, inspect local storage and tamper with traffic. This is where business logic and authorisation flaws come to light.

A sensible rhythm for most companies is automated checks on every build and a manual test before the first launch, before major releases and at least once a year. Our guide to penetration test costs in the UK explains how to scope that work and what to ask a provider.

UK and EU rules that apply to your app

UK GDPR. If your app processes personal data, you must protect it with appropriate security measures. The ICO can fine up to £17.5 million or 4% of annual worldwide turnover, whichever is higher.

Code of practice for app developers. The government’s Code of Practice for App Store Operators and App Developers (current version from October 2023) is voluntary, but it is the clearest statement of what the UK expects: a vulnerability disclosure process for every app, security updates (including when a third-party SDK gets a fix), encryption of data in transit, a way for users to request deletion of their data, and a plan for personal data breaches.

If you sell into the EU. EU GDPR applies to users there. The Cyber Resilience Act entered into force on 10 December 2024; obligations to report actively exploited vulnerabilities apply from 11 September 2026 and the main requirements from 11 December 2027. Whether a particular app falls within its scope depends on how it is distributed and monetised, so it is worth checking with your legal adviser. Startups can find the basics in our cybersecurity guide for startups.

How much does a mobile app security test cost in the UK?

The price depends on how many platforms are in scope, how many screens, flows and user roles the app has, whether the backend API is included, how deep the MASVS profile goes and whether a retest after fixes is part of the deal. CREST-accredited providers usually charge more. Senior testers in the UK typically bill between £1,000 and £2,500 a day.

Type of work	Typical scope	Indicative price
Automated scan with expert review	One platform, prioritised findings report	£800 – £2,500
Mobile app penetration test, one platform	iOS or Android, 3–5 days, MASVS baseline	£4,000 – £8,000
Mobile app test, both platforms plus API	iOS, Android and backend API, 6–10 days	£8,000 – £15,000
Resilience testing (MASVS-RESILIENCE)	Anti-tampering, root and jailbreak detection, obfuscation review	+£3,000 – £8,000
Retest after fixes	Verification of the fixed findings	£800 – £2,000

For a first figure for your own case, try our penetration test cost calculator.

How Yeeply can help

At Yeeply we work with certified companies that specialise in cybersecurity services for companies, including mobile app security testing against OWASP MASVS. We select and supervise them, put comparable proposals in front of you with clear scope, timeline and price, and follow the project until the findings are fixed and verified.

If you are building or rebuilding the app, the certified companies behind our mobile app development service work the same requirements into the specification from day one, which costs far less than fixing them after launch.

If you’d like a proposal, click “Receive price estimate” at the top right of yeeply.com/en or email us at sales@yeeply.com. Tell us which platforms you need tested, whether the API is in scope and when you plan to release.