Pricing Contact Case Studies Research Talk to a Pentester ↗
PoCForge / Application security / Mobile application penetration testing
POCFORGE / MOBILE

Mobile application penetration testing

Human-led testing of the Android or iOS build you ship, together with the API it calls. Local storage, platform controls and authorisation on the backend — evidence, then a retest.

  • Human-led
  • Every reported finding reproduced
  • Retest included
Request a free scope review →See starting prices
Isometric illustration of a smartphone between a locked on-device vault and a shielded backend server, with the heading "Mobile Application Penetration Testing", tagline "The app you ship and the API it calls", and the PoCForge logo.
  • Human testers leadTooling widens coverage only
  • Scoped firstScope and rules agreed before testing
  • Retest includedIn-scope fixes retested
  • Reproduced findingsEvidence a developer can replay

What we test

The build you ship

Release or release-candidate binaries, not a debug build that nobody will publish.

Details

Release or release-candidate binaries, not a debug build that nobody will publish. Platform, version and signing channel are written into the scope.

Local data

Tokens, files and caches on device storage, backups and logs.

Details

Tokens, files and caches on device storage, backups and logs. What another app or a stolen device could read after the user believes they logged out.

Transport

Details

Whether the app will talk to an unexpected host, and whether certificate checks can be switched off in the build under test. Pinning is a control we observe, not a certificate we award.

Platform features

Details

Deep links, custom schemes, WebViews, exported components on Android, and IPC between app extensions where those exist.

Authentication on device

Details

Biometrics and PIN gates that only hide the UI, session refresh, and shared web credentials that the app reuses.

The API behind the app

Details

The same authorisation questions as an API test, limited to what this app can call. A public API wider than the app is a separate scope.

Tamper and integrity signals

Details

What the app claims to detect, and whether a modest local change defeats a control the business relies on.

Privacy of what the UI hides

Screens that omit a field the API still returns.

Details

Screens that omit a field the API still returns. The finding is the data, not the pixels.

About this scope

The build matters more than the store listing. We test a release-like binary with accounts that should not be equal, and we follow the traffic into the API instead of stopping at the screen.

Client testing without ignoring the server

Example mobile app attack pathExample mobile app attack path (illustrative): app build, then secret or token on the device, then backend API, then another user's data. Example mobile app attack pathSTEP 1App buildSTEP 2Secret or token onthe deviceSTEP 3Backend APISTEP 4Another user’sdataIllustrative example. Real paths depend on what we find in scope.
Example mobile app attack pathExample mobile app attack path (illustrative): app build, then secret or token on the device, then backend API, then another user's data. Example mobile app attack pathSTEP 1App buildSTEP 2Secret or token on the deviceSTEP 3Backend APISTEP 4Another user’s dataIllustrative example. Real paths depend on what we find in scope.
Read more

A large share of mobile impact is an API problem reached from the phone. Treating the binary as a closed box, or the API as out of scope by default, produces a report that cannot explain account takeover or cross-user access. We scope the client and the backend calls together, and we say when a second platform is a second engagement.

We do not claim a MASVS certification or a store-compliance badge. Findings can be discussed against common mobile weakness classes so engineering has a vocabulary. The evidence is still the reproduction, not the label.

Fictional sample PoCForge "Application Security Assessment" report page with a blurred executive summary and a findings-by-severity chart, beside a High finding card for a missing authorisation check on a report export.

Deliverables

  • Executive summary that states platform, build and the API hosts covered.
  • Technical findings with device-side and server-side reproduction as appropriate.
  • A clear split between client fixes and API fixes, so the right team owns each item.
  • Retest notes against the build you send back.
More about the report

A report can support SOC 2 and ISO 27001 evidence. It does not certify the company, and it does not replace the auditor. PoCForge is not a certification body and does not claim CERT-In empanelment. If a contract names an empanelled auditor, read when CERT-In empanelment is required and check the official list before you shortlist.

Who this fits

A good fit

  • Teams shipping a customer app on Android, iOS or both, especially when the phone is how users reach payments, health data or a tenant workspace.
  • If you only wanted the backend, book API security testing and say the clients exist.

Worth knowing

  • Source code helps and is not mandatory; a testable build and accounts are.
More detail

Investment

Indicative $4,500 – $7,000 per platform before taxes. Price depends on build complexity and whether a deep API pass is included. Two platforms are not automatically double if they share one API and one role model — confirm that in scoping rather than assuming a discount or a premium. Start from the starting prices and the India mobile page.

TYPICAL INVESTMENT: $4.5K – $7K per platform · taxes as applicable · final quote based on scope.

Scope and rules

  • Platform and build. Android, iOS or both. Which build channel, which accounts, and whether the API is included.
  • Rules of engagement. Devices, production versus staging, and what we must not touch on real customer accounts.
  • Map client and API. Storage, deep links, and the calls each role makes. Undocumented routes the app uses are in scope if the host is agreed.
  • Test for impact. Local exposure and server authorisation. Tooling helps unpack the client; impact is judged by a tester.
  • Report. Findings tied to the build number, with steps a mobile and a backend engineer can split between them.
  • Retest. A new build in the window is retested against the original findings, not against every future feature.
Case study

Fintech API authorisation assessment

Anonymised fintech API authorisation assessment: how roles and money-adjacent endpoints were tested, the finding classes uncovered and how fixes were retested.

Read the case study →
How we work
  • Human-led
  • Every reported finding reproduced
  • Retest included

Related

Frequently asked questions

Do you test Android and iOS together?

They can be one programme or two. Each platform is priced and reported on its own build. Shared API findings are not pasted twice as if they were different bugs.

Is the API included?

The API this app calls is normally included. A public API used by other products is named separately so the scope does not sprawl.

Do you need source code?

No. A release-like build and test accounts are required. Source speeds up the work and can be added when you want a deeper pass.

Do you claim CERT-In empanelment?

No. PoCForge does not claim CERT-In empanelment. Use the CERT-In guide if an empanelled supplier is mandatory.

Will testing affect store users?

Not if we test a non-production environment or dedicated accounts, which is the default. Production testing is only with explicit rules and a rollback contact.

Scope a mobile assessment

Tell us the platforms, the build channel and whether the API is shared with the web app.

Request a free scope review →