API Security Testing
Analyze API endpoints for authorization flaws, data exposure, and abuse opportunities.
View service detailsMobile Application Testing · Central Illinois
Your app runs on a device you do not control, in the hands of someone who might not be a customer.
Every assumption a mobile app makes about its own runtime is negotiable. Certificate pinning can be patched out, jailbreak detection can be hooked, and client-side validation is a suggestion. We test what your app leaves on the device, what it says on the wire, and what its backend accepts once the client is no longer trustworthy.
What mobile application testing actually covers
Mobile application penetration testing covers three surfaces at once: the compiled application package, the app's behavior at runtime on a real device, and the backend services it talks to. Testing only the first two is common and largely pointless, because the majority of serious findings in mobile assessments live on the server side, reachable once an attacker has learned the protocol from the client.
We work against the OWASP Mobile Application Security Testing Guide and verify against MASVS, on physical jailbroken iOS and rooted Android hardware rather than emulators alone. Emulators miss hardware-backed keystore behavior, biometric flows, and a range of platform protections that only behave correctly on real devices, and those are frequently exactly what is being tested.
The reverse engineering work is not academic. We decompile the package, pull out hardcoded secrets, and read the logic behind feature gating and license enforcement. Then we instrument the running app to bypass client-side controls — root and jailbreak detection, certificate pinning, biometric gates — and see what the backend does when requests arrive from a client that is no longer behaving. That is the real test.
When you need this test
The app handles payments, health data, or identity
Banking, healthcare, insurance, and identity apps face both a higher attacker interest and specific regulatory expectations around data at rest on the device.
You are about to launch or have never tested
Pre-launch is the cheapest time to find an insecure storage pattern or a broken pinning implementation, because it is before the pattern has been copied into four more screens.
App store or enterprise distribution review is blocking you
Enterprise customers deploying your app via MDM increasingly require a MASVS-aligned assessment before approval.
You added offline mode or local caching
Anything that persists data on the device is a new storage surface. Offline sync features are a common source of unencrypted local databases full of production records.
You have client-side entitlements or licensing
If the app decides what a user is allowed to do, an attacker with a hooked runtime decides what they are allowed to do. Worth knowing before revenue depends on it.
What is in scope, and what is not
Included by default
- Static analysis: decompilation, hardcoded secrets, obfuscation quality, insecure API usage
- Local data storage: databases, preferences, caches, logs, keychain and keystore usage, backups
- Transport security: TLS configuration, certificate pinning implementation and bypass resistance
- Runtime manipulation: root and jailbreak detection, debugger and hooking defenses, tamper detection
- Platform IPC: deep links, custom URL schemes, exported activities and services, app extensions
- Backend API abuse from a modified or fully synthetic client
Excluded unless contracted
- Operating system or device firmware vulnerabilities
- Third-party SDK internals beyond their configuration and data handling
- App store distribution infrastructure
- Denial-of-service against backend services
Methodology, phase by phase
Every engagement follows the same documented arc. The percentages below describe how testing time is typically distributed — the balance shifts with what we find, but the phases do not change.
Scoping and environment setup
Before testing beginsWe confirm platforms, build variants, and test accounts, then prepare instrumented devices. Getting a build we can install is the single most common cause of delay, so we sort distribution before the window opens rather than on day one.
- Confirm iOS and Android scope, minimum supported versions, and whether tablet layouts differ materially
- Arrange build distribution via TestFlight, an internal track, or a direct package
- Provision test accounts per role and identify any backend rate limits or fraud controls that could interfere
Static analysis and reverse engineering
Roughly 25% of testing timeWe take the package apart. Decompiled code is reviewed for embedded credentials, weak cryptography, insecure defaults, and the logic behind any client-side security decision, along with the manifest or entitlements that define the app's platform attack surface.
- Decompilation and code review of the Android APK and iOS IPA
- Search for hardcoded API keys, credentials, private keys, and backend hostnames including non-production ones
- Manifest and entitlement review: exported components, permissions, backup flags, cleartext traffic policy
- Assessment of obfuscation and anti-tamper controls against the effort required to defeat them
Dynamic analysis on instrumented devices
Roughly 30% of testing timeThe app runs on rooted and jailbroken hardware while we watch everything it writes and sends. Runtime instrumentation lets us hook individual functions, which is how client-side security controls get tested honestly rather than taken at face value.
- Filesystem monitoring for credentials, tokens, and personal data written to storage, caches, and logs
- Keychain and Keystore review, including protection classes and whether hardware backing is actually used
- Certificate pinning bypass, then interception and modification of all application traffic
- Runtime hooking to defeat root and jailbreak detection, biometric gates, and client-side entitlement checks
Platform surface and backend abuse
Roughly 30% of testing timeWith the client fully under our control, we test what the platform exposes to other apps and what the server accepts from a client that is lying. This is where the high-severity findings usually appear.
- Deep link and custom URL scheme testing for unauthenticated actions and parameter injection
- Exported component testing on Android and inter-process communication review on iOS
- Backend authorization testing from a synthetic client: object-level access control, role enforcement, mass assignment
- Session and token handling: expiry, revocation, refresh flow abuse, and behavior after device compromise
Reporting and retest
5 business days after testing endsFindings are separated into what the client leaks, what the platform exposes, and what the backend fails to enforce, because those are three different teams and three different fixes. Client-side findings are rated by real exploitability rather than by whether a control exists.
- Per-platform findings with device evidence, screen recordings, and instrumentation scripts where useful
- MASVS verification results against the agreed level
- Remediation guidance covering both client changes and the server-side controls that should not have trusted the client
- Free retest of remediated findings within 90 days
Standards this maps to
Auditors, insurers, and enterprise security reviewers all ask which methodology a test followed. These are the published frameworks our process is built on, and the report names them explicitly.
- OWASP MASTG
- The Mobile Application Security Testing Guide provides the platform-specific test procedures for iOS and Android that our methodology executes.
- OWASP MASVS
- The Mobile Application Security Verification Standard is the requirements framework we verify against, with the target level agreed during scoping.
- PTES
- The Penetration Testing Execution Standard defines the engagement arc we follow: pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, reporting.
- CVSS v4.0
- Every finding carries a CVSS v4.0 vector so the base score is reproducible, plus a separate business-impact rating, because a 9.8 on a decommissioned host is not your biggest problem.
What you receive
A human writes your report. Not a scanner export with a cover page, and not a template with your logo dropped into it.
- Per-platform findings
- iOS and Android reported separately, because the same logical weakness often has different severity and a completely different fix on each platform.
- MASVS verification results
- Control-by-control results against the agreed MASVS level, in a format you can hand directly to an enterprise customer performing a security review.
- Device evidence
- Extracted files, screen recordings, intercepted traffic, and the hooking scripts used to bypass client-side controls, so your team can reproduce every result.
- Backend findings
- Server-side authorization and validation failures discovered through the modified client, reported with full request captures. These are usually the highest-severity items in the report.
- Hardcoded secret inventory
- Every credential, key, and non-production hostname recovered from the package, with a rotation priority — anything shipped in a binary should be treated as public.
- Attestation letter and retest report
- A shareable summary for app store and enterprise review processes, plus verification of your fixes within the included 90-day retest window.
Typical scope and duration
- Typical testing window
- 5–12 business days
- Report delivery
- 5 business days after testing ends
- Total elapsed time
- 3–5 weeks from kickoff
- Common scope size
- 1–2 platforms, 2–4 user roles
- Access required
- Installable build plus test accounts per role
- Retest window
- 90 days, included
What drives the price
We quote a fixed fee after a short scoping call. No hourly billing, no change orders mid-engagement. These are the variables that move the number:
- Whether one platform or both are in scope — the second platform adds meaningful time, not a rounding error
- How much of the application is native versus a web view wrapper, which shifts effort toward web testing
- The presence of anti-tamper, obfuscation, or attestation controls that must be defeated before testing can proceed
- Whether the backend API is included as a full assessment or only exercised through the client
- The number of user roles and whether offline or sync functionality exists
Frequently asked questions
How long does a mobile app penetration test take?
A single platform generally takes 5 to 8 business days of active testing; both iOS and Android together run 8 to 12. Report delivery is 5 business days after testing ends. Heavy obfuscation or attestation controls add time, since defeating them is a prerequisite to testing what is behind them.
Do you test on real devices or emulators?
Real, physically jailbroken and rooted devices, supplemented by emulators where they help. Emulators misrepresent hardware-backed keystore behavior, biometric flows, and several platform protections — which are frequently the exact controls under test.
Do you need the source code?
No. We decompile the shipped package, which is also what an attacker does, so black-box testing reflects reality. Source access speeds up static analysis and sharpens remediation guidance, and we are happy to work with it when you can share it.
Is the backend API included?
The endpoints the app calls are tested from a modified client by default, and that is where most high-severity findings come from. If you have a broader documented API with consumers beyond the mobile app, a dedicated API assessment covers it properly.
Our app has certificate pinning and jailbreak detection. Can you still test it?
Yes, and testing whether those controls survive contact with a determined attacker is part of the value. We defeat them through runtime instrumentation and report how much effort it took, which is the honest measure of a client-side control. They are speed bumps by design, not security boundaries — the report treats them that way.
How do we get you a build?
TestFlight for iOS, an internal testing track or direct APK for Android. We need a build that is functionally identical to production, and ideally one that is not pinned to a certificate we cannot swap. Sorting distribution before the testing window opens prevents the most common source of lost days.
Related engagements
Web Application Testing
Test modern web applications for logic flaws, auth issues, and exploitable vulnerabilities.
View service detailsIoT Security Testing
Assess connected devices, interfaces, and supporting infrastructure for real-world attack paths.
View service detailsNot sure this is the right test?
Tell us what you are trying to prove and to whom. A twenty-minute scoping call is usually enough to determine which engagement answers the question, and we will say so if the answer is a cheaper one.