Secure the server first. Most mobile app security best practices for a small product are the web and API controls it already needs, because anyone who installs a native app can unpack and read it. A client in the stores changes four things: no secret ships in the binary, tokens live in the platform’s secure storage, traffic is TLS only, and old versions stay installed.
What mobile app security covers, and what a native client changes
Mobile app security covers three layers: the user’s device, the app package you ship, and the backend it talks to. Only the backend is fully yours, because anyone who installs the app can unpack and inspect it. A native client adds storage, network and update concerns on top of the web controls.
Security for mobile apps starts from the controls a web product already needs, and the full list for this area is web app security: the twelve controls. The layers split like this, in my reading:
| Layer | Who controls it | Same as the web app? |
|---|---|---|
| The device and its operating system | The user, with Apple’s or Google’s platform protections | No: the web app never ran here |
| The app package | You write it, but it sits on the user’s phone | Partly: it plays the role the browser code plays for the web app |
| The backend and its API | You, and nobody else | Yes: the same server answers both clients |
How the middle layer looks depends on how the app was built. For a web app wrapped for the stores with Capacitor or a WebView, mobile web app security is the web app’s security plus the wrapper’s settings. For a React Native or Expo build, your JavaScript travels inside the package: Android’s docs describe the package as an archive file that “contains the contents of an Android app required at runtime” . How a website becomes a store app in the first place is covered in the four real paths from a website to a mobile app.
Each of the four changes has a plain reason. No secret ships in the binary, because every installed copy can be opened. Tokens live in the platform’s secure storage (the Keychain on iOS, or storage encrypted with an Android Keystore key), never in plain app preferences. Traffic is TLS only, with no cleartext exception left in the platform’s network settings. Old versions stay installed: OWASP’s mobile cheat sheet points to the “delay between when a patch is released and when users actually receive the updated version” , so a bug in the app can outlive its fix.
What stays the same is most of the work. Authentication, authorization, input handling, rate limits and secrets are decided on the server for both clients, which is why I treat web app and mobile app security as one program with two front ends. A mobile app is not safer than the website that shares its API; both are only as safe as the server checks behind them.
Why it matters for an app built with an AI builder
AI builders produce a mobile client the same way they produce a web one: the visible flow first, the server-side check later or never. That is my reading of how these tools work, and three counts from my audits show where it bites .
In my audits, 6 of the 21 third-party apps shipped a real secret . 11 of the 21 had unauthenticated endpoints doing privileged work . And 10 of the 21 trusted the client: the server accepted whatever the browser asserted .
Those 21 are the third-party apps I audited in June and July 2026: 11 public vibe-coded apps audited exhaustively across all 12 pillars, and 10 held-out apps audited blind . They are a selected set, not a random sample, so the counts are not a rate for AI-built apps in general. They also describe web code and servers, as the word “browser” in the last count shows, so read them as what a mobile client inherits, not as a measurement of mobile apps.
A native client makes each of the three worse in its own way. A secret in a bundle is in every installed copy and cannot be recalled. An unauthenticated endpoint is found by anyone who watches the app’s traffic on their own phone. A client the server trusts can be modified on the device, by the person who holds it.
The web version of the first problem is already on record: one browser-only app I audited loaded its paid AI provider key from a config file the live page has to serve, so anyone can read the key in the browser tools . The full case is the spam classifier that handed its billing key to every visitor. The lesson I take from it: a secret that ships to the client is everyone’s secret, and a mobile package ships to every phone that installs it. Keys in any client have their own page, API keys exposed on the frontend.
Mobile app security best practices: twelve controls, and which side each lives on
Mobile app security best practices for a small product come to twelve controls. Five live on the server and are shared with the web app, including authorization on every API action and no secrets in the package. Seven are new with a native client, led by secure token storage, TLS only and a forced-update path.
The table is also the order for how to secure mobile apps on a small team’s time: the five server rows first, because a fix there protects every user on every installed version at once. The side column and the checks are my reading; the platform facts come from Apple’s, Google’s and OWASP’s own pages, and the check numbers point to the eight checks further down.
| # | Control | Side | What to do | How to check it |
|---|---|---|---|---|
| 1 | Authorization on every API action | Server | Check the caller’s identity and permission on the server for every action | Replay calls as a second account and with no token (checks 4 and 5) |
| 2 | No secret in the app package | Server | Keep private keys on the server; ship only public identifiers, such as Supabase’s publishable key | Search the unpacked package (check 1) |
| 3 | Server-side input validation | Server | Validate every field on the server, not only in the app’s forms | Send a value the app’s form would block and expect a refusal |
| 4 | Rate limits and abuse controls | Server | Limit sign-in attempts and costly endpoints | Repeat a sign-in quickly from your own test account and expect throttling |
| 5 | The API as its own surface | Server | Assess the API directly, not only through the app | The endpoint list from check 3 |
| 6 | Secure token storage | Client | Keep tokens in the Keychain on iOS, or on Android encrypted with an Android Keystore key; never in plain preferences | Check 6 |
| 7 | TLS only | Client | No cleartext exceptions in App Transport Security or Android’s network security config | Check 2 |
| 8 | Deep links and URL schemes | Client | Validate every parameter and discard malformed links | Open a malformed link to your own app on your own device |
| 9 | WebView settings in a wrapper | Client | Load only your own origins; allow JavaScript bridges only for content you control | Read the wrapper’s config for its allowed origins |
| 10 | Logs, snapshots and debug builds | Client | Keep sensitive data out of logs and caches; ship release builds only | Confirm the store build is not debuggable |
| 11 | Third-party SDKs | Client | List every SDK and keep each one updated | Compare the list with your privacy declarations (check 8) |
| 12 | Minimum version and forced update | Client | Set a minimum supported version and a way to force an update | Raise the minimum on a test backend and open an old build |
Row 1 carries the most weight, and it is a topic of its own: broken access control . Row 5 means treating the API as a target in its own right, the way an API security assessment does .
For row 6, Apple describes Apple’s Keychain services as a way “to store small bits of user data in an encrypted database called a keychain” . On Android, the Android Keystore system “lets you store cryptographic keys in a container to make them more difficult to extract from the device” : it holds the key, and the token is stored encrypted with that key. Android’s own security checklist adds what kind of token to keep: after the first sign-in, “use a short-lived, service-specific authorization token” . Expo’s SecureStore does the same pairing, storing values in SharedPreferences “encrypted with Android’s Keystore system” and using the keychain on iOS . It carries one condition of its own. Expo’s page says “Large payloads can be rejected by the underlying platform.” It goes on: “Historically, some iOS releases refused values above roughly 2048 bytes.” Because “Expo does not enforce a limit” , a large stored session needs a check that the write succeeded.
For row 7, Apple’s App Transport Security requires HTTPS for HTTP connections made with Apple’s URL Loading System, and Apple’s page warns about exceptions: “Loosening ATS restrictions reduces the security of your app” . Android’s network security configuration sets the default by API level: “Starting with Android 9 (API level 28), cleartext support is disabled by default” , so an exception in that file is a choice someone made. Certificate pinning is optional, and it has a running cost: Android’s docs say to always include a backup key, because “Otherwise, you must push out an update to the app to restore connectivity” .
Row 8 exists because other apps can send yours a link . Apple’s guidance on custom URL schemes says they “offer a potential attack vector into your app, so make sure to validate all URL parameters and discard any malformed URLs” . Android’s docs add that “Android allows multiple apps to register intent filters for the same deep link URI” , so a link meant for your app can reach another one.
For a wrapper, row 9 follows Android’s security guidance: WebView objects “shouldn’t let users navigate to sites that are outside of your control”, and you should “never enable JavaScript interface support unless you completely control and trust the content” . In practice, in my reading, the wrapper loads your origin and nothing else, gets no access to local files it does not need, and any bridge between web code and native code answers only pages you serve.
OWASP’s mobile cheat sheet covers rows 10 to 12 in three lines: “Beware of caching, logging, and background snapshots”, “Ensure all third-party libraries are secure and up to date” and “Use a mechanism to force users to update their app version when necessary” . The forced update matters more than it looks, because a server-side change is the only fix that reaches a phone still running an old build.
The same cheat sheet also says “Obfuscate the app binary” . I treat obfuscation and tamper detection as depth for high-value apps, not a baseline, and never as a substitute for a server check: they slow down someone reading the package, and the server still has to refuse whatever the person holding the phone should not get.
Use the table as your mobile application security requirements list when a customer asks what you do about mobile, and read its last column as a mobile app security checklist you can run on your own build. Each of these mobile application security best practices has a check that needs no paid tool.
Mobile application authentication best practices
Mobile application authentication follows five rules: sign in through the system browser with PKCE, keep short-lived tokens in the Keychain or behind an Android Keystore key, treat biometrics as a local unlock and not authorization, revoke sessions on the server, and give the mobile client no endpoint with weaker checks than the web.
The first rule comes from an IETF best current practice. RFC 8252, OAuth 2.0 for Native Apps says “native apps MUST use an external user-agent to perform OAuth authorization requests” and “MUST NOT use embedded user-agents”, which rules out a sign-in page inside a WebView in your app . It also says “Public native app clients MUST implement the Proof Key for Code Exchange (PKCE [RFC7636]) extension to OAuth” .
Short-lived access tokens, with the refresh token held in the platform store and revocable on the server, keep a stolen phone from becoming a permanent session; lifetimes and signing are part of JWT security. Biometrics unlock a credential stored on the device. They are a convenience on top of a server session, never the authorization itself. Sign-out and lost-phone revocation happen on the server, which is why OWASP’s cheat sheet asks you to offer “a remote logout feature” .
The API treats the mobile client exactly like the web client, so there are no mobile-only endpoints with lighter checks. Lovable apps enforce data access through Supabase row level security policies, and Lovable’s security page says you can review every policy in your project under More → Cloud → Database → RLS policies . A mobile client that talks to the same Supabase project is bound by the same policies.
The OWASP Mobile Top 10: the list, its versions, and the standard behind it
OWASP publishes three mobile documents that are easy to mix up. The Mobile Top 10 is a list of the top mobile risks . MASVS is a standard of requirements and MASTG is a testing guide, and those two sit under the OWASP Mobile Application Security project . The four parts below say what each one is and where a small product’s fix lives for each risk. The web list is a different document, covered in how to test the OWASP Top 10 on a web app, which also says which web edition is the latest; the organization itself is covered in what OWASP is.
The mobile OWASP Top 10, 2024 edition: each risk and where its fix lives
The OWASP Mobile Top 10 is OWASP’s list of the ten top risks to mobile apps, with a 2024 final release . The same list covers Android and iOS apps . For a small product the useful question per risk is where the fix lives: in the app, on the server, or both.
OWASP’s Mobile Top 10 list for 2024 names ten risks, M1 to M10, and the first column copies each name as OWASP’s repository prints it . The meaning, the side and the control column are my reading. OWASP’s own home for the list is the OWASP Mobile Top 10 project .
| Risk, as OWASP prints it | What it means for a small product | Fix lives | Controls above |
|---|---|---|---|
| M1: Improper Credential Usage | Keys or passwords built into the app, or credentials stored or sent carelessly | Both | 2, 6 |
| M2: Inadequate Supply Chain Security | A compromised or outdated SDK or build step ships inside your app | Client | 11 |
| M3: Insecure Authentication/Authorization | The API lets a caller do what their account should not | Server | 1, 5 |
| M4: Insufficient Input/Output Validation | Input from the app, a deep link or the API is trusted without checks | Both | 3, 8 |
| M5: Insecure Communication | Traffic that can be read or altered on the way | Both | 7 |
| M6: Inadequate Privacy Controls | Personal data collected, logged or shared beyond what the feature needs | Both | 10, 11 |
| M7: Insufficient Binary Protections | The package is easy to read and modify | Client | 2, with obfuscation as depth |
| M8: Security Misconfiguration | Debug settings, cleartext exceptions, exposed components or loose server settings | Both | 7, 9, 10 |
| M9: Insecure Data Storage | Sensitive data kept on the phone outside secure storage | Client | 6 |
| M10: Insufficient Cryptography | Weak or home-made encryption | Client | 6 |
Counting the finished table, six of the ten need a fix on the server in whole or in part (M1, M3, M4, M5, M6 and M8), and only M3 lives on the server alone . Each row names a class of vulnerabilities rather than a single bug, so one OWASP Mobile Top 10 entry can hold several findings in a real test report, in my reading .
There is no separate Android or iOS OWASP Top 10. OWASP’s own risk pages name both platforms’ tools, as in M9’s advice to use “Keychain (iOS) or Keystore (Android)” , so one Mobile Top 10 from OWASP applies to an iOS app and an Android application alike.
OWASP Mobile Top 10 2014, 2016 and 2024: what changed
The OWASP Mobile Top 10 has three editions: 2014, 2016 and the 2024 final release, which is the current one . OWASP’s project lists no edition for any other year. Use the 2024 edition and cite OWASP’s own project page, not a vendor’s copy .
| Edition | How OWASP labels it | What to know |
|---|---|---|
| 2014 | Final List 2014 | Opened with M1: Weak Server Side Controls; replaced by later editions |
| 2016 | Final List 2016 | Opened with M1: Improper Platform Usage; replaced by the 2024 list |
| 2024 | Final release 2024 | The latest OWASP Mobile Top 10 and the one to use; its ten names are in the table above |
OWASP’s pages print no single release date for the 2024 Mobile Top 10 . The repository’s updates tab dates the list’s alpha to June 8, 2023, its beta to July 2, 2023 and its “Official initial release of the OWASP Mobile Top 10” to August 2, 2023 . The index links each of the ten 2024 risks to a page in a repository folder named 2023-risks , so OWASP Mobile Top 10 2023 files and the 2024 list are the same ten pages. OWASP does not say in words why the folder carries that year; my reading is that it follows those 2023 dates .
OWASP’s project page lists no 2025 edition of the Mobile Top 10, and none for 2017, 2018, 2019 or 2021 (checked September 28, 2026) . OWASP publishes the list on its project site and in its GitHub repository.
OWASP’s own comparison of the 2016 and 2024 Mobile Top 10 lists marks four 2024 risks as new (M1, M2, M4 and M6), shows 2016’s M4 and M6 merged into M3 and its M8 and M9 merged into M7, and moves Insecure Data Storage from M2 to M9 . The 2014 edition had put “M1: Weak Server Side Controls” first , an early sign of what this page argues: much of mobile risk sits on the server.
MASVS and MASTG: the mobile app security standards
MASVS is OWASP’s Mobile Application Security Verification Standard, a set of requirement groups a mobile app can be checked against. MASTG is its companion testing guide, with the processes, tools and test cases testers work from. With the Top 10 they make three documents: one for risk, one for requirements, one for testing.
OWASP’s Mobile Application Security project describes the MASTG as a guide “that covers the processes, techniques, and tools and test cases that enable testers to deliver consistent and complete results” . The latest MASVS release on GitHub is v2.1.0, from January 2024 . It groups its controls into eight areas: MASVS-STORAGE, MASVS-CRYPTO, MASVS-AUTH, MASVS-NETWORK, MASVS-PLATFORM, MASVS-CODE, MASVS-RESILIENCE and MASVS-PRIVACY .
The MAS site draws the same line this page does: “the MASVS only covers the security of the mobile app (client-side). It does not contain specific controls for the remote endpoints (e.g. web services) associated with the app” . The API behind your app needs its own standard, and the MAS site names the OWASP ASVS for it .
These mobile application security standards split the work for a small team, in my reading. The Top 10 is for talking about risk . MASVS is the requirements list to name when a customer asks which standard you follow. MASTG is what a hired tester should work from. Apple’s and Google’s platform pages sit beside all three for the storage and network rows .
Be wary of any claim of MASVS certification. OWASP’s position, in its own words: “OWASP, as a vendor-neutral not-for-profit organization, does not certify any vendors, verifiers or software” .
Mobile lists and tools: the OWASP Mobile Top 10 on GitHub, and Frida on Android
The OWASP Mobile Top 10 is maintained in a public GitHub repository, which is the source to cite . Frida, in its own words a dynamic code instrumentation toolkit, lets a tester observe and change a running app on a device they control . For an owner it proves one rule: decisions made only inside the app are not security.
The OWASP Mobile Top 10 GitHub home is OWASP/www-project-mobile-top-10, under the OWASP organization: the Mobile Top 10 repository on GitHub holds the index with all three editions . The MAS project keeps MASVS in a repository of its own, OWASP/masvs, where its releases are published . Cite those rather than a vendor’s restatement.
Frida’s documentation says it lets you “inject snippets of JavaScript or your own library into native apps” on platforms that include iOS and Android, with “full access to memory, hooking functions and even calling native functions inside the process” . Its site calls it “free software (free as in freedom)” .
Frida on Android matters to an owner for one reason, and this part is my reading: any check that runs only inside the app can be watched and altered by the person holding the phone. A hidden premium flag, a price worked out in the app, a test of whether the user is an admin, a root check: each runs on a device someone else controls, so the server must make the decision. OWASP’s cheat sheet says it in one line: “Assume all client-side controls can be bypassed and perform them server-side as well.” Testers use Frida on apps they are authorized to test, and this page gives no usage steps.
How to check your own app: mobile app security testing a founder can run
Mobile app security testing on your own build comes to eight checks: search the unpacked package for secrets, confirm TLS only, list every endpoint the app calls, replay calls as another account and with no token, confirm secure token storage, run an open-source scanner, and compare privacy declarations.
Run them on your own app, your own test accounts and your own devices only. Each check says what a pass and a fail look like, and together they make a mobile security test you can repeat before every release.
- 01 Search the package for secrets. Unzip your Android release APK (Android's docs call it an archive file) and search the contents for the first dozen or so characters of each real secret key your backend holds (Stripe, your AI provider, Supabase's sb_secret_ key), copied from wherever you keep the keys. Any match is a fail. Bare prefixes such as sk- or sk_ also sit inside ordinary words, so treat those hits, and hits for the word secret, as leads to read one by one, never as a fail on their own. Then decode every string that starts with eyJ: Supabase's legacy service_role key is a JWT, while its new publishable and secret keys are short strings, not JWTs. A JWT whose role is service_role, or anything else that is not a public identifier, is a fail.
- 02 Confirm TLS only. Open the release build's App Transport Security settings and its Android network security config, and confirm there is no cleartext exception. A debug build may allow cleartext for a local development server; the release build should not.
- 03 List every endpoint. Route your own test device through an intercepting proxy you control and write down every host and endpoint the app calls: that list is your API surface. An app that pins certificates will refuse the proxy, which is expected, so use a debug build you own. On Android, only apps targeting API level 23 and lower trust user-added certificates by default, so the debug build needs the debug-overrides setting, whose certificates are trusted only when android:debuggable is true.
- 04 Replay calls as a second account. Take three of those calls, swap in a second test account's Authorization header or cookie, and aim them at the first account's records. The server must refuse or return none of those records; keep the status code and body as evidence. On a Supabase backend, row level security hides rows a policy does not allow instead of raising an error, so an empty result or zero rows changed is a pass.
- 05 Call with no token. Send the same calls with no user token at all. The pass rule is the same: a refusal, or none of the records.
- 06 Find where the token lives. Confirm the session token sits in the iOS Keychain, or on Android is encrypted with a Keystore key. A token in plain preferences or a plain file is a fail.
- 07 Run an open-source scanner. Run a static scanner such as MobSF over the release package, iOS or Android, and read every high finding. The tools are in the next section.
- 08 Compare privacy declarations. List what each SDK in the app collects and check that the store listings' privacy answers say the same.
How to fill in those privacy answers is covered in the app privacy answers a builder’s app needs and, for Android, Google Play’s Data safety form.
On a Mac or Linux machine, check 1 on an Android build looks like this, with your own file name and the start of each real key in place of the placeholder . The last line searches for the bare sb_secret_ prefix , so in my reading a hit there is a lead to read like the other prefixes, and only a full key is a fail:
unzip -l app-release.apk | head -40
unzip -q app-release.apk -d apk-contents
grep -rl "FIRST_12_CHARS_OF_A_REAL_KEY" apk-contents/
grep -rl "sb_secret_" apk-contents/Keep the evidence: the search output, the endpoint list, the refused requests, the scanner report, the date and the build number. Among mobile app security testing best practices, order is the one I would not skip, and this is my working rule: run the server checks, 3 to 5, first, because they affect every user on every installed version . OWASP’s cheat sheet lists the same no-token test for pentesters, to “execute backend server functionality anonymously by removing any session tokens” .
A mobile app security review by an outside tester starts from the same list, and which kind of scan proves what is explained in SAST vs DAST. Security testing on mobile applications you do not own is out of bounds for everything on this page.
Mobile application security testing tools, open source first
Mobile application security testing tools fall into three groups: open-source analysis such as MobSF and the OWASP testing guide, commercial automated testing platforms, and in-app protection products. A scanner reports what is in the package. None of them fixes a server that trusts the client.
The open-source mobile app security testing tools below are where I would start, and the last column says who should run each one.
| Tool | Kind | What it tells an owner | Who should run it |
|---|---|---|---|
| MobSF | Automated framework for static and dynamic analysis of Android, iOS and Windows apps | What sits in the package, read from APK and IPA files | You, on your release build |
| OWASP MASTG | Testing guide whose test cases each map to a MASVS control | What a thorough test covers, per platform | Your tester; for you, a reading list |
| Frida | Dynamic instrumentation toolkit | Why checks inside the app are not security | A hired tester, on apps they are authorized to test |
| An intercepting proxy of your choice | Traffic inspection | Every endpoint the app calls (check 3) | You, on your own device and debug build |
MobSF describes itself as “an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing, malware analysis and security assessment framework capable of performing static and dynamic analysis”, and its static analyzer reads “APK, IPA, APPX and source code” . That makes it the one mobile app penetration testing tool in this table that scans the package itself, for iOS and Android alike. Frida and the tools built on it are mobile app pentesting tools for the tester you hire, not for an owner’s release routine. OWASP also warns against treating a scan as a test, whatever mobile application pentesting tools produced it: “It is not sufficient to simply run a tool and report on the failures” .
Commercial mobile app security software comes in two classes, named here as classes, with no ranking. Automated testing platforms scan your builds; NowSecure describes its platform as “Continuous, automated, integrated mobile app security testing” . In-app protection products harden the package itself: Guardsquare’s site lists code hardening and runtime application self-protection, and Zimperium’s lists application shielding . In my reading, a scanner finds what is in the package and a shield raises the cost of tampering, and neither changes what your API accepts. Any mobile application security software, and any of the mobile app security solutions sold under that name, is worth comparing only after the eight checks, so you know which gap you are paying to close.
Mobile pentesting and mobile app penetration testing services: what you are buying
A mobile app penetration testing service is an authorized, time-boxed test of your Android and iOS packages and, if you put it in scope, the API behind them. You receive a report with findings and fixes, and a retest if one is agreed. Ask which standard the tester works from and whether the API is in scope.
The Production Hardening Sprint covers one codebase , and none of the 123 deliverables on its published scope page tests a native mobile app package (iOS or Android) on a device . This section is here to help you buy the right mobile penetration testing from whoever sells it.
In practice, a mobile application penetration test covers the app package on Android and iOS and, where agreed, the backend it talks to. The MASTG is the OWASP testing guide such tests can work from , but it stops at the app: “Testing the app’s remote endpoints is not covered in the MASTG” . Penetration testing for mobile apps therefore needs the API named in scope on its own. The parts below are my reading of the MASTG’s structure, as a way to compare offers for a mobile application penetration testing service.
| Part of the test | What the tester does | What you receive |
|---|---|---|
| Static analysis of the package | Reads the unpacked app for secrets, settings and risky code | Findings with the file or setting involved |
| Dynamic analysis on a test device | Runs the app on a controlled device and watches what it does | Findings with steps to reproduce |
| Storage and network checks | Checks what the app keeps on the phone and how it talks to the server | Findings against the storage and network controls |
| The API as its own target | Calls the backend directly, outside the app, with test accounts for each role | Authorization and input findings on the server |
| Report and retest | Writes up severity, reproduction and fixes, then retests if agreed | The report, then the retest result |
Mobile app security testing services sell you a test and mobile application security consulting sells you advice, which in my reading is the main difference between the two labels. The general questions to ask any tester (static or dynamic, roles tested, evidence, retest, which requirement the report must satisfy) are in how to compare what pentest vendors offer. For a mobile test, add four:
- 01 Confirm which platforms are in scope: the Android build, the iOS build, or both.
- 02 Confirm whether the API is in scope by name, since the MASTG does not cover remote endpoints.
- 03 Ask whether each finding will be mapped to a MASVS control.
- 04 Ask which builds, test devices and test accounts the tester needs; OWASP's recommended open-book review includes access to at least one user account for each role.
What a web test covers is in web application penetration testing, and what a small test costs, with sources, is in affordable penetration testing. The paperwork that goes with a test is a separate topic and stays out of this page. If the mobile client is a thin wrapper around your web app, most of the risk sits in the API, in my reading, so an API-focused test plus the eight checks above is a reasonable first purchase to consider . That changes when a customer contract names a mobile penetration test: then buy the test the contract names.
Where the sprint fits
Five deliverables of the Production Hardening Sprint relate to this topic. Deliverable 1.3 enforces permissions on every protected route, API endpoint and server action . Under 2.1, the sprint removes all private secrets from frontend code and downloadable bundles, relocating their use to server-side code . Deliverable 2.3 verifies that service-role and administrative keys are used exclusively in protected server environments . Under 3.7, the sprint reviews the application against the OWASP Top 10 and records findings, fixes and evidence by category . Deliverable 3.10 tests the five highest-risk externally reachable attack surfaces, and AxonBuild performs this targeted test ; the targeted security tests cover the five priority attack surfaces documented in the report . The boundary is the one stated in the pentest section above, plus one more: formal third-party certifications and independent audit opinions are separate from the sprint deliverables . Deliverables 3.7 and 3.10 sit in the security area of the published scope, and 1.3, 2.1 and 2.3 in the two areas before it .
Common questions about securing a mobile app
What are the top 3 mobile vulnerabilities according to OWASP?
The top 3 in OWASP’s 2024 Mobile Top 10 are M1: Improper Credential Usage, M2: Inadequate Supply Chain Security and M3: Insecure Authentication/Authorization . The numbers are OWASP’s own ordering, and its methodology prioritizes risks by their “impact and likelihood of occurrence” . For a small product, M3 is the one fixed on the server.
What is OWASP in Android?
OWASP in Android means the same three mobile documents OWASP publishes for every platform: the Mobile Top 10, the MASVS standard and the MASTG testing guide, which has Android chapters on data storage, network communication and platform APIs. Android’s own security docs tag risks with MASVS categories, for example “MASVS-PLATFORM: Platform Interaction” on its page about deep links .
Is the mobile app secure?
A mobile app is as secure as the server checks behind it, plus a handful of client controls for storage, network settings and updates. Only a check of your own build answers that for your app, and the eight checks above are how an owner finds out .
What are the common mobile security threats?
OWASP’s mobile cheat sheet groups the threats and their controls under architecture and design, authentication and authorization, data storage and privacy, network communication, user interface, code quality, application integrity, testing, post-deployment, and advanced hardware security and monitoring, plus platform-specific guidance for Android and for iOS and iPadOS . Authentication, authorization and most of the architecture work are handled on the server; storage, network settings, the user interface and app integrity are handled in the app.
The checks in this guide show you where the app is open. The sprint below closes those gaps, tests the result and writes the evidence down.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase