Why a mobile-specific checklist matters
Web app pentesting and mobile app pentesting are fundamentally different disciplines. Mobile apps run on devices you do not control, in environments you cannot predict, with local storage you cannot protect from a rooted device. The OWASP MASVS defines eight categories of mobile security verification. We have adapted them here with specific focus on what matters for Nigerian fintech apps processing real money.
This is the checklist we use internally at Simpa Labs when conducting mobile penetration tests for fintech clients. It is not exhaustive - every app has unique attack surfaces - but it covers the critical areas where we consistently find vulnerabilities.
1. Data storage and privacy
Mobile devices get stolen, shared, and backed up to the cloud. Every piece of sensitive data stored locally is a liability.
- No sensitive data (credentials, tokens, PINs, financial data) in SharedPreferences, UserDefaults, or unencrypted SQLite databases.
- No sensitive data in application logs (Logcat on Android, Console on iOS). Check both debug and release builds.
- No sensitive data in clipboard. Disable copy/paste on sensitive input fields.
- No sensitive data in application backups. Set
android:allowBackup="false"on Android. Exclude sensitive data from iOS backups usingNSURLIsExcludedFromBackupKey. - No sensitive data in keyboard cache. Use
android:inputType="textNoSuggestions"andautocorrectionType = .noon iOS for sensitive fields. - Encryption at rest using platform keystores (Android Keystore, iOS Keychain) for all credentials and tokens. See our comparison in the iOS vs Android security guide.
- No KYC data (BVN, NIN, photos) stored locally after upload is confirmed.
2. Cryptography
Broken or weak cryptography exposes everything the encryption was meant to protect.
- No hardcoded encryption keys in the source code or binary.
- No deprecated algorithms (MD5, SHA1, DES, 3DES, RC4). Use AES-256-GCM for symmetric encryption, RSA-2048+ or ECDSA P-256 for asymmetric.
- No custom cryptographic implementations. Use platform-provided or vetted libraries (Tink, CryptoKit, libsodium).
- Proper key management: keys stored in hardware-backed keystores, not in code or configuration files.
- Adequate random number generation using SecureRandom (Android) or SecRandomCopyBytes (iOS) for all security-critical operations.
3. Authentication and session management
The authentication flow is the primary target for account takeover attacks.
- All authentication happens server-side. No client-side-only auth checks.
- Biometric authentication is backed by hardware keystore, not a simple boolean check.
- Session tokens have appropriate expiry and are rotated after authentication events.
- Sessions are invalidated on the server when the user logs out - not just cleared locally.
- Concurrent session handling: detect and alert on multiple simultaneous sessions.
- Re-authentication required for sensitive operations (fund transfers, profile changes, PIN changes).
- Password/PIN entry has rate limiting and lockout after failed attempts.
- See our detailed guide on mobile banking session management.
Client-side biometric bypass
The single most common critical finding in Nigerian fintech mobile pentests: biometric authentication that checks a local boolean flag rather than requiring cryptographic proof from the hardware keystore. An attacker on a rooted device can hook the biometric callback with Frida and always return "success" - bypassing fingerprint or face verification entirely. The fix is to use BiometricPrompt with a CryptoObject tied to an Android Keystore key.
4. Network security
All communication between the app and backend must be protected against interception.
- All traffic uses TLS 1.2 or later. No cleartext HTTP for any endpoint.
- Certificate pinning implemented for API endpoints with backup pins and rotation strategy.
- Network security config (Android) properly configured with cleartext traffic disabled.
- No sensitive data in URL parameters - use POST bodies or headers for tokens and credentials.
- Custom certificate trust stores: app does not trust user-installed certificates in production.
5. Platform interaction
How the app interacts with the OS and other apps on the device.
- No exported components (Activities, Services, Content Providers, Broadcast Receivers) that expose sensitive functionality without proper permission checks.
- Deep links and custom URL schemes validate all parameters and do not expose sensitive operations.
- WebViews restrict JavaScript execution, validate loaded URLs, and do not expose
JavascriptInterfaceto untrusted content. - No unnecessary permissions requested. Each permission has a documented justification.
- Inter-process communication (IPC) does not leak sensitive data to other apps.
6. Code quality and build configuration
- Debug mode disabled in release builds.
android:debuggable="false"verified. - No hardcoded API keys, credentials, or secrets in the binary.
- Code obfuscation enabled (ProGuard/R8 for Android, Dart obfuscation for Flutter).
- Stack traces and verbose error messages not exposed to users in release builds.
- All third-party libraries and SDKs updated to latest stable versions with no known CVEs.
7. Resilience against reverse engineering
For fintech apps, resilience against reverse engineering is not optional.
- Root/jailbreak detection implemented and enforced for sensitive operations.
- Emulator detection prevents running in analysis environments.
- Debugger detection rejects runtime attachment (Frida, LLDB, GDB).
- Integrity verification checks the app's signature and binary integrity at runtime.
- Response to tampering: app should degrade gracefully (not crash) and alert the backend.
Want this checklist tested against your app by security engineers who do this every day? We will assess every category, document findings with severity ratings, and deliver a remediation roadmap.
Book a Mobile App Pentest8. API security (the mobile app's backend)
A mobile pentest is incomplete without testing the APIs the app communicates with. This overlaps with our API security assessment scope:
- Broken Object Level Authorization (BOLA): can user A access user B's data by changing IDs?
- Rate limiting on authentication endpoints, OTP verification, and fund transfer APIs.
- Input validation: SQL injection, NoSQL injection, and command injection on all API parameters.
- Webhook security: HMAC verification, idempotency, replay protection.
- Proper error handling that does not leak internal details (stack traces, database errors, infrastructure information).
When to test
Do not wait until the Play Store rejects your app. Test before your first launch, before each major release, after integrating new payment or KYC SDKs, and at minimum annually. The cost of a pentest is a fraction of the cost of a breach, and the investment scales with your app's complexity.
Related reading
Blog: 10-Point Fintech Security Checklist · How Our Pentest Works · Security Audit Before Launch
Guides: Mobile App Pentest Nigeria · OWASP for Fintech · How to Book a Pentest
Services: Penetration Testing · API Security · Vulnerability Assessment
Frequently asked questions
When should a Nigerian fintech get a mobile app pentest?
Before your first production launch, before any major feature release that touches payments or authentication, after integrating new third-party SDKs, and at least annually for compliance. CBN-regulated entities should test after any significant architecture change. Read our guide on pentest timing for more detail.
What is the difference between OWASP MASVS and MASTG?
MASVS (Mobile Application Security Verification Standard) defines what to test - the security requirements. MASTG (Mobile Application Security Testing Guide) defines how to test - the testing methodology and tools. Together they form the industry standard for mobile app security testing.
How long does a mobile app pentest take?
A thorough mobile app pentest typically takes 5-10 business days depending on app complexity, the number of platforms (Android/iOS), and the scope of API testing. Simple apps with few features may take 3-5 days. Complex fintech apps with payment flows, KYC, and multiple user roles typically need the full 10 days.