Cyber Security Testing
Mobile Apps Security Testing
Android and iOS binary, runtime and API-layer assessment against OWASP MASVS.
Every engagement includes manual validation, a two audience report and free re-testing.
Get a scoped quote+91 96682 00222What this actually is
A mobile app is not a website in a smaller window. The binary sits on a device you do not control, in the hands of someone who may be actively trying to pull it apart. Anything you shipped inside it, an API key, a hidden endpoint, the logic that decides whether a payment succeeds, is there to be read.
We test the app the way a determined attacker would. Decompile the binary, hook the runtime, strip out certificate pinning, and see what it does once the client can no longer be trusted. Then we test the API behind it, because that is usually where the real damage is.
Most of the serious findings we report on mobile are not in the app at all. They are in an endpoint that assumed the app would only ever send well-behaved requests.
What we go after
- Static analysis of the compiled binary for secrets and logic
- Runtime manipulation, hooking and anti-tamper bypass
- Certificate pinning and transport security
- Local storage, keychain, keystore and cache exposure
- Authentication, session handling and biometric bypass
- Backend API authorisation with the client removed
- Deep link, intent and inter-process communication abuse
- Root and jailbreak detection effectiveness
How we run it
- 01
Scope and authorise
Targets, testing windows, escalation contacts and safety limits, all agreed in writing before anyone touches anything.
- 02
Map the surface
We enumerate what is actually exposed, which is usually more than the asset register says.
- 03
Test by hand
Tooling gives coverage, our engineers give proof. Every finding is reproduced before it is written down.
- 04
Report
An executive narrative your board can act on, and a technical annexe with the exact request, payload and fix.
- 05
Re-test and sign off
Once you have fixed it we verify each one at no extra cost, then close the engagement properly.
What you receive
- Findings for both the app and the API behind it
- Decompiled evidence and runtime proof for each issue
- Risk rated by what an attacker actually gains
- Remediation guidance your mobile team can act on
- Free re-test once the next build ships
Who needs this
Anyone with a customer-facing Android or iOS app, particularly in banking, payments, health and government services where the app handles identity or money.
How long it takes
One to two weeks per platform, plus the API surface behind it.
Standards this satisfies
- OWASP MASVS
- OWASP MASTG
- CERT-In
- PCI DSS
- RBI
Why it matters
A mobile app ships to the attacker's device. They can decompile it, watch its traffic, tamper with its storage and run it on a rooted phone. Anything you rely on the client to enforce is not a control, it is a suggestion.
For regulated apps it is also a compliance question. RBI, UIDAI and the app stores each have expectations about storage, certificate handling and rooted device behaviour, and an assessment is how you evidence them.
Choose the depth you actually need
Most of the price difference between quotes comes down to this one choice, and it is rarely explained. Pick one to see what it covers, what it suits and what it costs you.
You give us working accounts at each privilege level and a short walkthrough. We then test what a real attacker reaches after the first stolen password, which is where the findings that matter almost always live. This is what we recommend for most engagements.
Choose this when
- Any application with authenticated functionality
- Multi-tenant products, where tenant isolation is the real risk
- Getting the most findings for the money
Effort and cost
Moderate effort and by far the best coverage per rupee. Most of the serious findings we report come out of authenticated testing rather than unauthenticated.
Tested against OWASP ASVS, not a checklist we invented
We test to the OWASP Application Security Verification Standard, which sets verification levels across authentication, session management, access control, input validation, cryptography, error handling and business logic. Working to a published standard means you can tell an auditor or a customer exactly what was verified and to what depth. It also makes this year's test comparable with last year's, which a bespoke in-house checklist never is.
Scope it yourself, before you call anyone
Answer a few questions and you get an indicative number, the working behind it and what your answers tell us. It runs in your browser, so nothing you type reaches us.
What needs testing?
Pick everything in scope. Effort is driven by unique functionality, not by how many IP addresses you own.
What we look for, and keep finding
These are the classes of problem this work exists to surface. Not every engagement finds all of them, but these are the ones that turn up often enough to be worth naming.
Broken access control
The most common serious finding we report, and the one scanners miss most reliably. An identifier that is not checked against the caller, an admin function reachable by guessing its path, a role that can be changed in the request. The user is logged in. They are simply reading or doing something that is not theirs.
Injection and unsafe query construction
SQL, NoSQL, OS command and template injection. Modern frameworks prevent most of it, which is exactly why the remaining cases hide in the hand written query somebody added under deadline, or in the reporting module nobody has looked at since it shipped.
Authentication and session weaknesses
Tokens that do not expire, password reset flows that can be redirected, multi-factor that can be skipped by replaying an earlier step, and sessions that survive a password change. We test the whole lifecycle rather than just the login form.
Business logic abuse
Nothing is technically broken. The application simply allows a sequence it should not: a discount applied twice, a payment confirmed before it clears, a limit avoided by splitting a request. This requires understanding what the application is for, which is why automation cannot find it.
Sensitive data exposure
Data returned by an API that the interface never displays, secrets in client side code, verbose errors that reveal structure, and personal data in logs. The response body is where we find most of it.
Security misconfiguration
Default credentials, directory listing, debug endpoints reachable in production, permissive CORS and missing security headers. Individually minor, and routinely the first step in a chain that ends somewhere serious.
Who runs your engagement
A senior tester, named before you sign
Testing is led by an engineer holding OSCP, CREST or equivalent, and you are told who it is before the engagement starts. They write the report themselves rather than handing notes to someone else, and they are on the call when findings are walked through. If the person changes, we tell you why.
Questions we get asked
Do you test both Android and iOS?
Yes. They fail in different ways and we price them separately, but most clients do both because the API behind them is shared, and that is where the crossover findings appear.
We use certificate pinning. Does that not stop this?
It stops casual interception. It does not stop us, and it will not stop anyone serious. Pinning is worth having, but it should never be the control your security depends on.
Do you need our source code?
No. We work from the binary by default, because that is what an attacker has. If you give us source as well we will use it, and we will find more.
Often scoped alongside
- Web Application Security TestingOWASP-aligned manual and automated testing of web applications, with validated proof-of-concept for every finding.Read more
- Network Penetration TestingInternal and external network exploitation, lateral movement and privilege escalation testing.Read more
- API Security TestingAuthentication, authorisation, rate-limiting and business-logic testing across REST, GraphQL and gRPC.Read more
- Cloud Penetration TestingAWS, Azure and GCP configuration review, IAM privilege analysis and cloud-native exploitation.Read more
Ready to scope your mobile apps security testing?
Thirty minutes with a senior engineer, and you leave with a written scope and indicative effort.