Mobile App Penetration Testing Guide (iOS & Android)
What a mobile app pentest covers on iOS and Android, how OWASP MASVS shapes it, what testers need from you, and the issues that come up most often.
Application testing
Secure Code Review
We read the code that protects your business, line by line, and point to exactly where and how to fix it.
- OWASP ASVS
- CWE Top 25
Overview
Some flaws are easy to see from the outside. Others hide in the code: a single handler that skips an access check, a query built from user input, a key committed three years ago. A pentest finds what is reachable. A code review finds what is there.
Our reviewers focus on the code that protects your business, such as authentication, payments and data access, and read it with an attacker’s mindset. Every finding points to exact lines, explains why it matters and shows how to fix it. Combine it with a pentest for white-box testing and you get the depth of both.
Scope
What we test
- Authentication and session management code
- Authorization checks and multi-tenant data access
- Payment, billing and pricing logic
- Input validation and output encoding
- Database queries and ORM usage
- Cryptography and key management
- Secrets committed to code or configuration
- File handling, uploads and deserialisation
- Error handling and logging of sensitive data
- Third-party dependency risk
- Infrastructure-as-code and CI/CD configuration, where in scope
Findings
Common issues we find
Generic examples of what this kind of testing tends to uncover. Every engagement is different, and we never share client findings.
Critical
Missing authorization in a single code path
Most endpoints call the access-check helper, but one forgotten handler does not.
High
Queries built from user input
String concatenation or raw queries that bypass the ORM's protections.
High
Secrets in the repository
API keys, tokens or passwords committed to code, config files or git history.
High
Weak or misused cryptography
Homemade encryption, static IVs, outdated hashing for passwords or keys stored next to the data.
High
Unsafe deserialisation or template rendering
Untrusted data passed to deserialisers or template engines that can execute code.
Medium
Sensitive data written to logs
Tokens, passwords or personal data captured in application logs and error reports.
Medium
Vulnerable dependencies in reachable code
Known-vulnerable libraries used in a way that exposes the vulnerable function.
Severity shown is typical, not fixed. We rate each finding on its real impact in your environment.
Approach
How we test it
Agree what matters most
We review your architecture with your team and choose the modules where a flaw would hurt most, such as authentication, payments and data access.
Trace the data
We follow untrusted input from where it enters to where it is used, and check every trust decision along the way.
Review by hand
Our reviewers read the code, supported by static analysis for coverage, and confirm every issue rather than passing on raw tool output.
Map findings to code
Each finding points to the exact file and lines, explains the risk and shows a fix that fits your framework and coding style.
Deliverables
What you receive
Every finding comes with proof-of-concept evidence, so your engineers can reproduce it and your auditors can trust it.
Executive summary
A plain-English view of risk for leadership, boards and customers.
Technical findings
Each issue with impact, evidence, reproduction steps and a clear fix.
Free retest
Once you’ve fixed the findings, we retest them and update the report.
Attestation letter
A letter you can share with customers and auditors to show testing was done.
Preparation
What we need from you
We'll confirm the details during scoping. Having these ready helps testing start on time.
- Read-only access to the repositories in scope
- A short architecture walkthrough with a lead developer
- Build or run instructions, if we will verify findings dynamically
- A list of priority modules and any known concerns
- A technical contact for questions during the review
FAQ
Secure Code Review testing questions
Do you review the whole codebase?
For large codebases, a focused review of the most critical modules gives far more value than a shallow pass over everything. We agree the focus during scoping.
Which languages do you review?
We review common web, mobile and backend languages and frameworks. Tell us your stack during scoping and we will confirm coverage.
How is this different from a static analysis tool?
Tools are good at spotting patterns but generate many false positives and miss logic flaws. Our reviewers understand what your code is meant to do and verify every finding by hand.
Can you combine code review with a pentest?
Yes. White-box testing, with code access during a pentest, lets us confirm issues faster and find flaws that are hard to reach from the outside.
How is our source code handled?
Under NDA, with read-only access, stored encrypted and deleted after the agreed retention period. See our Trust page for details.
Guides
How to Read a Penetration Test Report
How to read a penetration test report: what severity ratings mean, how to judge the evidence, which findings to fix first, and how the retest closes the loop.
Related services
Web Application Penetration Testing
Manual testing of your web app's authentication, access control and business logic, the places scanners can't reach.
API Penetration Testing
Hands-on testing of REST, GraphQL and gRPC APIs for broken authorization, data exposure and abuse of business logic.
Thick Client Penetration Testing
Deep testing of desktop applications on Windows, macOS and Linux, from local secrets and updates to the servers they talk to.
Need a pentest for an audit, a customer, or peace of mind?
Tell us what you need tested. You’ll get a fixed-fee proposal with tester-days and timeline stated, usually within a few days of the scoping call.