This piece was written for enterprise technology leaders and originally published on the Wednesday Solutions mobile development blog. Wednesday is a mobile development staffing agency that helps US mid-market enterprises ship reliable iOS, Android, and cross-platform apps — with AI-augmented workflows built in.
Eight audit categories, what to check in each, what failure looks like, and what to do when you find a problem two weeks before launch.
73% of enterprise mobile apps fail at least one security audit category before launch, according to NowSecure's 2024 Mobile Security Report. The most common failures are not exotic zero-days - they are basic hygiene problems: sensitive data stored in plaintext, API keys hardcoded in the app binary, and third-party SDKs accessing device data with no one tracking what they collect. This playbook covers the eight categories a CTO needs to check before any major mobile release, what a failure looks like in each, and what to do if you find something critical two weeks before the launch date.
Key findings
73% of enterprise mobile apps fail at least one security audit category before launch (NowSecure, 2024).
Hardcoded API keys in app binaries are the most exploitable single-point failure - anyone who downloads the app can extract them.
A professional penetration test runs $15,000-$50,000. Running one only at initial launch misses every vulnerability introduced by subsequent changes.
Below: the full eight-category audit, what to check in each, and how to handle a late-breaking finding.
Data storage security
What to check: Any data the app writes to the device must be assessed for sensitivity and encryption status. The audit categories are local database files (SQLite, Core Data, Room), shared preferences or NSUserDefaults, temporary files and caches, and clipboard access.
How to check it: On iOS, use a jailbroken device or a tool like iMazing to browse the app's Documents and Library directories. On Android, use Android Debug Bridge to pull the app's data directory. Look for any file containing tokens, credentials, PII, or financial data that is not encrypted. Check NSUserDefaults on iOS and SharedPreferences on Android specifically - developers frequently store session tokens there because it is convenient, and neither is encrypted by default.
What failure looks like: A session token or bearer credential stored as plaintext in SharedPreferences. A SQLite database containing user transaction history with no encryption layer. A temporary file created during a PDF export that persists after the export completes.
The fix: Sensitive data on device belongs in the platform keychain (iOS Keychain, Android Keystore). Temporary files must be purged after the operation that created them. Local databases containing PII require file-level encryption using a key derived from the user's credentials.
Network security
What to check: Every network call the app makes should use TLS 1.2 at minimum, with TLS 1.3 preferred for any call carrying credentials or financial data. Certificate pinning should be active for calls to your own backend. The audit should map every outbound domain the app connects to.
How to check it: Run a TLS intercept proxy (mitmproxy or Charles) on a device with the app installed. Watch the network log for any unencrypted HTTP calls. Check the TLS version on every HTTPS connection. Attempt to swap the app's expected certificate with a self-signed certificate - if the app accepts it, certificate pinning is either not implemented or misconfigured.
What failure looks like: Any call over HTTP rather than HTTPS. A TLS 1.0 or 1.1 connection to a legacy backend. A certificate pinning check that fails open (accepts any valid certificate) rather than failing closed (refuses the connection). An analytics SDK making calls to a domain you did not know the app was connecting to.
The fix: Enforce HTTPS with App Transport Security on iOS and Network Security Configuration on Android. Set minimum TLS version to 1.2 in your network library configuration. Implement certificate pinning for your primary API domains using public key pinning rather than certificate pinning, so that certificate rotation does not require an app update.
Authentication and session management
What to check: Session token generation, token storage, token expiry, biometric authentication implementation, and what happens when a token is revoked server-side.
How to check it: Capture a valid session token using a network proxy. Log out, then replay the captured token against the API - if the server accepts it, session invalidation is not working. Check the token expiry: short-lived tokens (under four hours) with refresh token rotation are the target. Test biometric authentication by asking: if biometric fails, what is the fallback, and does that fallback inherit the same security posture?
What failure looks like: A session token that remains valid after logout. Tokens that never expire. A biometric fallback that downgrades to a four-digit PIN when the backend requires full credentials. Session tokens stored in a location accessible without device unlock.
The fix: Server-side session invalidation on every logout event. Tokens expire in four hours with a refresh flow requiring active session validation. Biometric authentication should unlock a key in the device's secure enclave, not bypass server-side authentication. Store session tokens in the platform keychain, never in application storage.
API security
What to check: Whether API keys are embedded in the app binary, whether API endpoints validate the caller's identity on every request, and whether the app exposes more API surface area than it needs.
How to check it: Decompile the app binary using a tool like apktool (Android) or class-dump (iOS). Search the output for strings matching common API key patterns: long alphanumeric strings, strings labeled "key", "secret", "token", or "api". Check whether requests to your backend include both a session token and a per-request signature. Test API endpoints directly, bypassing the app, to see whether they enforce authentication independent of the app client.
What failure looks like: A Google Maps API key, Stripe publishable key, or internal service key embedded as a string constant in the app binary. API endpoints that trust the app client to enforce authorization rather than doing it server-side. An admin endpoint reachable from the app with a standard user session.
The fix: API keys belong in a server-side proxy call, not in the app binary. If a key must live on the device, it should be delivered at runtime via an authenticated call, not compiled in. Backend endpoints must validate authorization on every request, independent of the client.
Third-party SDK audit
What to check: Every SDK in the app must be mapped to what device data it accesses, what it sends off-device, and what the privacy policy of its vendor says about data use. The most common risks are analytics SDKs with broad device permissions and advertising SDKs that collect device identifiers.
How to check it: Pull the dependency manifest (Podfile.lock for iOS, build.gradle for Android). For each SDK, check the vendor's privacy documentation against what permissions the SDK declares in its manifest. Use a tool like Exodus Privacy or NowSecure to scan the app for tracker SDKs. Cross-reference SDK permissions against your app's declared privacy policy - any data an SDK collects that your policy does not disclose is a compliance problem.
What failure looks like: An analytics SDK with permission to read the contact list that your privacy policy does not mention. An advertising SDK from a third-party ad network that your team integrated six months ago and no one audited. An SDK that is no longer maintained and carries a known CVE.
The fix: Maintain a dependency inventory with the last audit date for each SDK. Every SDK upgrade triggers a re-audit of its permissions. Remove SDKs that are no longer needed. For SDKs that require broad permissions, assess whether the functionality can be replaced with a more targeted library.
App Store binary analysis
What to check: What can be extracted from the app binary by someone who downloaded it from the App Store. The goal is to understand what an attacker with the app on their device can learn about your architecture.
How to check it: Download your own app from the App Store. Unpack the IPA or APK. Run strings extraction on the binary to find hardcoded values. Use a decompiler to assess whether the business logic is readable. On Android, check whether ProGuard or R8 obfuscation is active. On iOS, check whether the binary includes debug symbols that should have been stripped.
What failure looks like: Internal API endpoint URLs visible in the binary. Error messages that expose server architecture details ("PostgreSQL connection failed at 10.0.1.45"). Debug build artifacts in the release binary. A decompiled Android app where class names are fully readable, exposing the data model.
The fix: Strip debug symbols before release. Enable obfuscation on Android. Treat any URL or configuration value in the binary as potentially public. Remove all error messages that reference internal infrastructure. Run binary analysis as part of every release pipeline, not as a one-time audit.
MDM policy compliance
What to check: If the app is distributed through a Mobile Device Management system (for internal enterprise apps) or is expected to run on MDM-enrolled devices (for B2B apps), the app must behave correctly under MDM policy constraints.
How to check it: Enroll a test device in your MDM platform (Jamf, Intune, VMware Workspace ONE). Apply the strictest policy set your enterprise users operate under. Install and run the app. Check: does the app function under app wrapping? Does it respect data-sharing restrictions between managed and unmanaged apps? Does the app block screenshots when MDM policy requires it? Does it handle remote wipe of app data without data loss side effects?
What failure looks like: The app crashes under app wrapping because it uses a framework that conflicts with the MDM wrapper. A managed app that allows users to copy data to unmanaged apps (email, cloud storage) when the MDM policy prohibits it. A remote wipe command that corrupts local cache files rather than deleting them cleanly.
The fix: Test against every MDM platform your enterprise clients run. Build explicit support for Managed App Configuration keys if the app serves enterprise B2B use cases. Data sharing restrictions require explicit support in the app's file handling code - they do not apply automatically.
Penetration test scope and cost
A professional penetration test is distinct from an internal audit. An auditor checks that controls are configured correctly. A penetration tester actively tries to break the app, using the same techniques an attacker would use.
Scope for a standard enterprise mobile penetration test covers the eight categories above plus backend API testing, authentication bypass attempts, session hijacking tests, and reverse engineering of the app binary. A full-scope test for a mid-complexity enterprise app takes three to five days of tester time.
Cost ranges: a targeted mobile-only test (app binary and API, no backend infrastructure) runs $15,000-$25,000. A full-scope test including backend infrastructure, network, and cloud configuration runs $30,000-$50,000. Retesting after remediation typically adds $5,000-$8,000.
When to run it: before the first major public launch, before adding a payment flow or authentication change, before any compliance certification (SOC 2, HIPAA, PCI DSS), and on an annual cycle for apps handling financial or health data. A single pre-launch test is not a security program.
How to choose a tester: look for a firm with OSCP-certified testers, mobile-specific methodology (OWASP MASVS is the standard), and a track record in your industry. Ask for a sample report before engaging - the report quality tells you as much about the firm as any certification does.
When you find something two weeks before launch
Two weeks out is not ideal. It is also not a reason to delay.
Triage by exploitability first. A hardcoded API key is exploitable immediately - anyone with the app binary has the key. A missing certificate pin is exploitable only on a compromised network. A debug symbol in the binary is an information risk, not a direct exploit path. Rank the findings by how quickly an attacker could cause damage, not by how bad they look on paper.
For findings that are exploitable immediately, fix before launch. For a hardcoded API key, the fix is less than a day of engineering work: rotate the key, remove it from the binary, gate it behind a server-side call. For an unencrypted local database, encrypting an existing SQLite database on first upgrade takes one to two days.
For findings that require architecture changes - a session management redesign, a full certificate pinning implementation - assess whether a mitigating control buys time. Temporarily restricting the exposed functionality while the full fix ships in the next release is a defensible decision if the risk is documented and the timeline is specific.
Document every finding, its risk classification, its remediation status, and the person accountable for the fix. If a finding ships unresolved, the documentation needs to show it was a deliberate risk acceptance decision with a named owner and a fix date, not an oversight.
Want to go deeper? The full version — with related tools, case studies, and decision frameworks — lives at mobile.wednesday.is/writing/mobile-app-security-audit-playbook-cto-2026.