Mobile applications occupy a security position distinct from web applications: distributed widely as binaries, reverse-engineered routinely, executed on a platform the operator does not control, with credentials and identity material baked into the deployment artifact. Companion applications for connected products add the device-pairing protocol and the local-network attack-surface to that picture.
Melina supports mobile-app security across consumer iOS and Android applications, companion apps for connected products, and enterprise mobile applications.
What this service covers
Static binary analysis
Static analysis of the deployed binary — what an attacker can do without launching the app on a test device:
- Credential handling — hardcoded secrets, embedded API keys, hardcoded encryption keys
- Certificate pinning — implementation completeness, bypass resistance
- Debug interfaces left in production builds — logging that exposes sensitive data, debug menus accessible through input sequences
- Reverse-engineering posture — obfuscation effectiveness, anti-tamper mechanisms
- Third-party SDK inventory and supply-chain risk
Dynamic analysis
Runtime behavior on instrumented test devices:
- IPC surface — exported services, broadcast receivers, content providers (Android); URL schemes, app extensions (iOS)
- Deep-link handling — authentication-bypass paths through deep-link payloads
- Local data storage — encryption, keychain / keystore usage, residual data after app removal
- Insecure communication patterns — TLS configuration, certificate validation, cleartext fallback
- Biometric and platform-authentication integration
Server-side API testing from mobile-client perspective
Server-side APIs called from mobile clients have a distinct threat model from web applications. The client is untrusted code on an untrusted platform. We test the API surface specifically from that perspective:
- Authorization gaps — endpoints that rely on client-side authorization decisions
- Replay and request-tampering resistance
- Rate-limiting and abuse-resistance
- Tenant isolation where multi-tenant
- Token handling — expiration, refresh, revocation, scope
Companion-app security for connected products
For mobile applications that pair with connected devices (smart-home, wearables, industrial IoT, automotive companion apps):
- Pairing protocol analysis — BLE, Wi-Fi handoff, local-network discovery
- Command-flow security — what authority the app has over the device, how the authority is delegated
- Local-network attack-surface — mDNS, SSDP, custom discovery protocols
- Cloud-relay path — when the app and device communicate through cloud infrastructure rather than direct local connection
Platform-specific attack surface
Platform-specific issues that materially affect security posture:
- iOS: keychain usage patterns, App Group sharing, App Extension boundaries, Universal Links handling
- Android: keystore usage, intent filters, exported component permissions, Content Provider exposure, Custom Tabs and WebView configuration
- Cross-platform frameworks (Flutter, React Native): framework-specific bridging considerations and the security implications of the JavaScript/Dart boundary
Methodology
Each mobile engagement follows our six-stage methodology: Discovery, Scoping, Threat Modeling, Testing, Reporting, 60-day Re-check. Mobile testing typically uses both jailbroken / rooted instrumented test devices and stock-platform devices to surface platform-side issues that emerge only with stock security boundaries in place.
What this service does not include
- App-store rejection-risk consulting — that’s a separate discipline tied to platform-policy expertise rather than security expertise
- Reverse-engineering of competitor apps without their authorization — out of scope as a matter of policy
Compliance and standards we work within
- OWASP Mobile Application Security Verification Standard (MASVS)
- OWASP Mobile Security Testing Guide (MSTG)
- NIST SP 800-163 (mobile-application security)
- ISO/IEC 27001:2022 Annex A controls where mobile features
- China-market: PIPL for personal-information processing; sector-specific guidance (financial-sector mobile-banking, healthcare-app guidance)
- App-store security expectations (Apple App Review, Google Play Protect)
Engagement model
| Scope | Engagement model |
|---|---|
| Single-application assessment | Scoped Assessment |
| Multi-application or cross-platform suite | Custom Engagement |
| Per-release continuous engagement | Retainer |
“Mobile applications operate on platforms the operator doesn’t control, with credentials baked into the deployment artifact. The threat model is materially different from web applications, and the assessment scope needs to reflect that. Most mobile findings we discover are server-side — the mobile client just happens to be how an attacker exercises the underlying API authorization gap.” — Gleb Z., CTO, Melina Security
What buyers ask us first
Three questions surface in nearly every initial discovery call with a mobile or companion-app team:
“Is the highest-value scope the mobile binary or the server-side API?” Server-side, in most engagements. Mobile clients are untrusted code on untrusted platforms — most exploitable conditions live in the API surface that trusts client-side decisions it shouldn’t. Mobile binary analysis remains valuable for credential handling, certificate pinning, and reverse-engineering posture, but the highest-impact findings typically come from the server-side API tested from the mobile-client perspective.
“How does companion-app testing differ from standard mobile testing for connected products?” Companion-app testing adds the device-pairing protocol and the local-network attack surface to the standard mobile scope. The pairing protocol (BLE, Wi-Fi handoff, local-network discovery), the command authority delegated to the app, and the local-network attack surface (mDNS, custom discovery) are companion-specific scope items that pure mobile testing doesn’t cover. For connected-product manufacturers, companion-app testing without device-pairing scope misses the most consequential surface.
“Can pre-release builds be assessed before App Store / Play Store submission?” Yes — pre-submission assessment is often higher-leverage than post-launch testing because findings can change app behaviour before the deployment artifact is locked. We work with release-candidate builds; for findings that require debug instrumentation, we coordinate specific test builds with documented differences from the release build.
Frequently asked questions
Do we need to provide source code, or can you work from the binary?
Both options are supported. Binary-only assessment matches the attacker’s actual position and surfaces the issues that real attackers can find. Source-code assisted assessment is faster and provides better coverage of internal logic flaws that are hard to reach through binary analysis alone. Many engagements run hybrid — binary-first analysis with source-code consultation for areas where the binary analysis surfaces interesting questions.
Will testing require us to ship a special debug build?
For most assessment scopes, no — we work against the release-candidate build that matches what will ship to users. Where specific testing requires debug instrumentation that the release build does not support, we coordinate a specific test build with documented differences from the release build.
How do you handle certificate pinning during dynamic analysis?
Pinning bypass is part of the assessment scope — we evaluate pinning implementation completeness and bypass resistance directly. Once pinning is assessed, we use instrumented test devices with controlled bypass to access the server-side API surface during the broader testing phase.
Do you assess App Store / Play Store compliance?
Tangentially. App-store compliance assessment is a separate discipline tied to platform-policy expertise. We surface security findings that are likely to draw app-store-review attention — for example, undocumented data collection or unencrypted credential transmission — but we don’t issue formal app-store-compliance attestation.
Will our companion-app testing require physical access to the paired device?
For companion-app testing scopes that include device-pairing protocol analysis: yes, ideally during the on-site engagement portion. Where physical access to production hardware is constrained, we work with engineering samples or development units provided by the client.
How does mobile-app assessment coordinate with AI/ML integration testing?
For mobile applications integrating LLM or other AI features, the assessment scope extends to include the AI-integration boundary. We coordinate with the AI/ML Security engagement team to cover the integration surface: prompt construction, retrieval-augmented context handling, tool-invocation authorization from the mobile client, and output handling. The boundary-pattern findings documented in our Five-Boundary Taxonomy apply directly to mobile AI integration.
Related
- Industries — IoT and connected-device manufacturers
- Industries — Automotive — companion-app integration
- Companion research: Five-Boundary Attack-Surface Taxonomy for LLM Applications (for AI-integrated mobile apps)
- What is prompt injection? — for AI-integrated mobile apps
- Methodology