Penetration testing · PTaaS

A senior engineer breaks your app, then hands you the fix.

Automated scanning tells you where the obvious problems are. It does not tell you whether someone can actually take over an account, move money they should not, or read another customer's data. That takes a person. Mobexa puts a senior offensive engineer on your Android or iOS app, working to the OWASP MASTG, to prove what an attacker can really do and to show you exactly how to close it.

Android & iOS OWASP MASTG Signed report Free retest
Request a pentest See how automated testing fits
What we test

The whole attack surface, not just the binary

We test the app the way it is really attacked: the code that ships, the device it runs on, and the backend it talks to. The scope maps to the OWASP MASTG so you can see exactly what was and was not covered.

Authentication & sessions

Login, token handling, session fixation and lifetime, biometric and PIN flows, account recovery, and whether a second factor can be skipped.

Authorization & logic

The findings scanners miss: reading another user's records, acting above your role, replaying or tampering with requests, and business flows you can abuse for profit.

Network & API

We sit in the middle of the app's traffic, defeat certificate pinning, and test the backend the app reaches: broken object-level access, injection, and endpoints that trust the client.

Data at rest

What the app writes to the device: tokens, personal data and cached files, keychain and keystore use, and whether any of it survives on a lost or shared phone.

Resilience

Root and jailbreak checks, anti-tamper and anti-instrumentation, and how far the app can be pushed on a hostile device before it stops protecting money and identity.

Platform interaction

Exported components and deep links, IPC, WebView bridges to native code, clipboard and screenshot exposure, and the ways one app on the phone can talk to yours.

How an engagement runs

Five stages, one clear owner

Every engagement runs the same way, so you know what happens and when. You get a named engineer, not a queue. We start from a real build and real credentials, because that is what an attacker who downloads your app already has.

Book a scoping call
  1. Scope. A short call to agree the app, the user roles, the backend in reach, and anything off-limits. You get a fixed timeline and a fixed fee before you commit.
  2. Recon. We run our own static and dynamic tooling first, so the engineer spends their time on judgment, not on the obvious.
  3. Exploitation. Hands on the app on an instrumented device: defeat the defenses, reach the sensitive flows, and prove what actually works.
  4. Chaining. The real work. Combine small findings into a full attack, abuse the business logic, and test the paths that only open once you are inside.
  5. Report & retest. A written report with reproduction steps, severity, business impact and fixes. When you have patched, we retest and confirm each issue is closed.
What you get

A report your engineers and your auditors both trust

No wall of low-severity noise. Every finding is one an attacker would care about, proven, ranked by what it costs your business, and paired with a fix a developer can act on.

Proven findings

Each issue comes with the exact steps to reproduce it and a proof of concept. Nothing lands in the report that we could not do ourselves.

Impact, not just severity

We rate findings by what they let an attacker do to your users and your business, so the fix order is a business decision, not a CVSS lottery.

Fixes a developer can use

Concrete remediation for each finding, mapped to the MASVS control behind it, written for the person who has to change the code.

Executive summary

A one-page read for the people who sign off risk, without the jargon, so the report works in the boardroom and the sprint.

Signed report

A dated, signed document you can hand to a customer, a partner or an auditor as evidence the test happened and what it found.

Free retest

Once you have fixed the issues, we confirm each one is closed and reissue the report as dated proof.

Testing plus a platform

A pentest catches the deep bugs. The platform keeps them caught.

A point-in-time pentest is honest about one thing: the moment it ends, your next release can undo it. That is why the human test and our automated platform belong together. The engineer finds the logic flaws and the chained attacks a scanner cannot. The platform then watches every release after, so a fixed problem does not quietly come back three sprints later.

If you ship often, run continuous: we retest each significant release and keep the report current. If you need a point-in-time test for an audit or a launch, we do that too.

Talk to us about scope See platform pricing
Common questions

Straight answers

What is mobile application penetration testing?
It is a hands-on security assessment where an engineer attacks a real build of your Android or iOS app the way a motivated attacker would: pulling the app apart, running it on an instrumented device, defeating its defenses, and chaining small weaknesses into a real breach. The result is a list of proven findings with reproduction steps and fixes, not a scanner dump.
How is a pentest different from an automated scan?
A scanner finds the known-shaped problems at scale: hardcoded secrets, weak crypto, exported components, cleartext traffic. A human finds the things a scanner cannot reason about: broken authorization, logic you can abuse, insecure flows that only appear once you are logged in, and attacks that only work when you combine two findings. We run both, and the scan makes the human faster.
How long does a mobile app penetration test take?
A single-app engagement usually runs one to three weeks from scoping to signed report, depending on the size of the app, the number of user roles, and how much backend the app talks to. We agree the timeline in a short scoping call before you commit.
Do you retest after we fix the findings?
Yes. A retest of the fixed issues is included. We confirm each finding is actually closed and update the report, so you have evidence the work was done, not just a promise.
Can you test on a schedule instead of once a year?
Yes. You can book a point-in-time test for a release or an audit, or run continuous testing where we re-test every significant release. Most teams that ship often move to continuous once they see how fast a yearly test goes stale.

Put a real attacker on your app before a real one does.

Tell us the app and what you are worried about. We will come back with scope, timeline and a fixed fee.

Request a pentest