When I audit apps, I almost never find exotic vulnerabilities. I find API keys committed in the code, tokens stored in plain text, backend endpoints that trust the app instead of verifying the user, and dependencies three years out of date. Security failures are overwhelmingly failures of routine. So instead of a threat-landscape essay, here is the actual checklist I run — twelve checks, in plain language, so you can ask your developer pointed questions even if you don't code.
1–3: How Data Lives on the Device
One: sensitive data is stored only in platform secure storage — Android Keystore-backed encryption or iOS Keychain — never in plain SharedPreferences, files, or unencrypted local databases. Two: auth tokens have expiry and rotation; a stolen token that works forever is a stolen account forever. Three: nothing sensitive leaks into logs, crash reports, or analytics events — I have seen full request bodies, passwords included, sitting in a third-party crash dashboard. Ask your developer to show you what your crash tool actually receives.
4–6: How Data Travels
Four: all traffic is HTTPS with no cleartext exceptions — both platforms enforce this by default now, so any exception in your config was added deliberately and needs justification. Five: certificate pinning for high-value flows — payments, auth — so a compromised network can't intercept them; but implemented with a rotation plan, because pinning without one eventually bricks your own app. Six: no sensitive data in URLs, ever — URLs end up in server logs, proxies, and referrer headers.
7–9: The Backend Trusts Nobody
Seven: every API endpoint enforces authorisation server-side — the deadliest common bug is an API that returns any user's data if you change an ID in the request, because the developer assumed only the app would ever call it. Attackers do not use your app; they use your API directly. Eight: rate limiting on auth and OTP endpoints, or your login page becomes a free password-testing service and your SMS budget an attacker's toy. Nine: server-side validation of purchases and entitlements — receipt validation on your backend, not just in the app, or patched clients get your product for free.
10–12: The Software Supply Chain
Ten: dependencies are current and monitored — a vulnerability in a library you ship is a vulnerability in your app, and 2026 tooling makes automated dependency alerts effortless, so not having them is a choice. Eleven: secrets are not in the codebase — API keys, signing configs, and service credentials belong in secure configuration, not in a repository that every past contractor still has cloned. Twelve: code obfuscation and integrity checks appropriate to your risk — R8 and app attestation raise the effort for tampering and cloning; they don't make an insecure app secure, but they stop the casual attacks that make up the volume.
The Compliance Layer on Top
Stores now enforce parts of this: privacy declarations must match observed behaviour, data-safety forms are audited against actual network traffic, and India's DPDP Act plus the EU's rules give data handling legal weight. The checklist above is not just good practice — mismatches between what your app does and what your store declaration claims are now a rejection and takedown risk. Have one person who can truthfully answer 'what data do we collect and where does it go' — in writing.
How to Use This Checklist
Send these twelve points to your development team and ask for a yes, no, or not-applicable on each — in writing. A good developer answers in an afternoon and will respect you for asking. Vague answers are themselves a finding. If you'd rather have an independent pair of eyes, I run this exact audit against client apps — code, backend behaviour, and store declarations — and deliver a prioritised findings report with realistic remediation costs. It is a fixed-price engagement, and the contact form is the place to start.