LaunchLint Academy
The short answer
- Mobile security does not begin with one scanner. Use your data and threat model to select controls for storage, cryptography, authentication, network, platform interaction, code, and privacy.
- Static repository review finds valuable signals early. It does not replace runtime tests, backend review, or a risk-appropriate penetration test.
- Do not postpone this checklist until submission day. Make it a release gate, link every item to the responsible commit or store field, and repeat affected checks after changes to dependencies, permissions, production configuration, or metadata. Supporting records must not contain secrets or personal test data. Engineering, product, and the person who controls the store console should approve the same artifact. This turns a one-off review into a reproducible process and makes it possible to explain exactly what was checked after a rejection or during the next update.
1. Map data and threats
Classify credentials, personal content, location, payments, and business secrets together with plausible attackers and impact.
Do not treat map data and threats as an isolated checkbox. Tie the claim to the exact release build, a named owner, and reviewable supporting detail. Repeat the path on a clean device and record any mismatch before the store submission continues.
Evidence for release acceptance
- Production value for map data and threats recorded
- Affected file or store setting linked
- Expected and observed behavior compared
- iOS and Android differences reviewed deliberately
- Every uncertainty has an owner and due date
- Release stops when a blocking contradiction remains
2. Keep secrets out of the client
Private API keys, service credentials, and signing material must not ship in the mobile bundle or public configuration.
Do not treat keep secrets out of the client as an isolated checkbox. Tie the claim to the exact release build, a named owner, and reviewable supporting detail. Repeat the path on a clean device and record any mismatch before the store submission continues.
Evidence for release acceptance
- Production value for keep secrets out of the client recorded
- Affected file or store setting linked
- Expected and observed behavior compared
- iOS and Android differences reviewed deliberately
- Every uncertainty has an owner and due date
- Release stops when a blocking contradiction remains
3. Secure local storage
Tokens and sensitive values belong in platform keychain or keystore facilities rather than logs, general storage, or plaintext files.
Do not treat secure local storage as an isolated checkbox. Tie the claim to the exact release build, a named owner, and reviewable supporting detail. Repeat the path on a clean device and record any mismatch before the store submission continues.
Evidence for release acceptance
- Production value for secure local storage recorded
- Affected file or store setting linked
- Expected and observed behavior compared
- iOS and Android differences reviewed deliberately
- Every uncertainty has an owner and due date
- Release stops when a blocking contradiction remains
4. Authentication and authorization
The server validates sessions and permissions for every sensitive action; hiding a control in the UI is not authorization.
Do not treat authentication and authorization as an isolated checkbox. Tie the claim to the exact release build, a named owner, and reviewable supporting detail. Repeat the path on a clean device and record any mismatch before the store submission continues.
Evidence for release acceptance
- Production value for authentication and authorization recorded
- Affected file or store setting linked
- Expected and observed behavior compared
- iOS and Android differences reviewed deliberately
- Every uncertainty has an owner and due date
- Release stops when a blocking contradiction remains
5. Protect network traffic
TLS, certificate validation, production endpoints, and cleartext restrictions must align across both platforms.
Do not treat protect network traffic as an isolated checkbox. Tie the claim to the exact release build, a named owner, and reviewable supporting detail. Repeat the path on a clean device and record any mismatch before the store submission continues.
Evidence for release acceptance
- Production value for protect network traffic recorded
- Affected file or store setting linked
- Expected and observed behavior compared
- iOS and Android differences reviewed deliberately
- Every uncertainty has an owner and due date
- Release stops when a blocking contradiction remains
6. Control platform boundaries
Deep links, exported Android components, URL schemes, WebViews, clipboard, and screenshots can move data across app boundaries.
Do not treat control platform boundaries as an isolated checkbox. Tie the claim to the exact release build, a named owner, and reviewable supporting detail. Repeat the path on a clean device and record any mismatch before the store submission continues.
Evidence for release acceptance
- Production value for control platform boundaries recorded
- Affected file or store setting linked
- Expected and observed behavior compared
- iOS and Android differences reviewed deliberately
- Every uncertainty has an owner and due date
- Release stops when a blocking contradiction remains
7. Dependencies and updates
Packages, native SDKs, and build configuration are inventoried, updated, and reviewed for unnecessary capability and known risk.
Do not treat dependencies and updates as an isolated checkbox. Tie the claim to the exact release build, a named owner, and reviewable supporting detail. Repeat the path on a clean device and record any mismatch before the store submission continues.
Evidence for release acceptance
- Production value for dependencies and updates recorded
- Affected file or store setting linked
- Expected and observed behavior compared
- iOS and Android differences reviewed deliberately
- Every uncertainty has an owner and due date
- Release stops when a blocking contradiction remains
8. Operate a security gate
Static findings, runtime tests, backend controls, privacy, and incident ownership receive one release decision.
Do not treat operate a security gate as an isolated checkbox. Tie the claim to the exact release build, a named owner, and reviewable supporting detail. Repeat the path on a clean device and record any mismatch before the store submission continues.
Evidence for release acceptance
- Production value for operate a security gate recorded
- Affected file or store setting linked
- Expected and observed behavior compared
- iOS and Android differences reviewed deliberately
- Every uncertainty has an owner and due date
- Release stops when a blocking contradiction remains
Frequently asked questions
Is OWASP MASVS only for banking apps?
No. Its control groups can be applied proportionally to apps of different risk.
Can a repository scan find every vulnerability?
No. Runtime, server, business logic, and final artifacts require additional testing.
Can a public API key ship in an app?
Only when designed as a public client identifier and effectively restricted on the server side.
Does LaunchLint perform a penetration test?
No. LaunchLint is a static release-oriented review, not a complete penetration test.