SysTools
VAPT Service

Mobile Application VAPT

Security testing of your Android and iOS apps — checking what the app stores on the phone, how it talks to your servers, how logins work, and whether the app itself can be tampered with. Please answer what you can; anything you are unsure of can be settled on the scope call.

Progress 0% 0 of 0 answered 0 mandatory pending

Before you start

  • Please do not type real passwords, API keys, signing keys or tokens into this form. Those are shared separately through a secure channel.
  • We only test the app builds you list here. Fields marked * are needed before testing can begin.
  • If you are not sure about something, pick "Not sure" or leave a note — we will go through it with you on the scope call.

1 Assessment Details

Mandatory

2 Scope and Testing Approach

Mandatory

Grey Box — you give us the app build and login details. White Box — you also share source code and design details. Black Box — we start with only the public store listing, so more of the time goes into finding things rather than testing them.

Please note: this is not included in the timeline estimate in section 7. The estimate covers one round of testing only. How often it repeats is agreed when the scope is finalised.

3 Application Details

Decides the timeline

Rough numbers are fine. Leave anything blank if it does not apply.

The app

Android builds in scope
iOS builds in scope
Screens or pages, approximate

Users and inputs

User roles or permission levels
Average input fields per screen
Screens handling payments or money

Connections

API collections integrated
Third-party SDKs or services
Login / SSO integrations

Count an Android build and an iOS build of the same app as two — they store data differently and are tested separately. A screen is one page the user sees, for example "login" or "transfer money".

If cross-platform, tell us which framework in the box below — it changes how we take the app apart.

We only test the builds listed here. Add one row per platform — an Android and an iOS build are two rows.

If it works offline, data has to be kept on the phone — that is one of the most common places sensitive information leaks.

Things built by someone else that the app relies on — payments, maps, analytics, chat, push notifications.

If the APIs are left out, we can still see the traffic, but we will not actively test the server side. Permission and access-control problems usually live there.

4 Data and Standards

Affects how serious a finding is

This decides how serious a finding is, so an approximate answer is fine. Anything unusual can go in the notes below.

5 How We Test

Nothing here needs an answer — it is what you are buying.

How the assessment runs

We take the app apart and read it without running it, then install it on a test device and watch what it actually does — what it saves on the phone, what it sends to your servers, and what it writes into logs. Automated tools cover the obvious ground and every result is checked by hand before it reaches your report. The bulk of the time is manual testing. Each finding is reproduced, evidenced and written up with clear fix guidance, and once you release a fixed build we retest against it.

What we look for

What the app leaves behind on the phone — account details, tokens, cached data — and whether it is protected. Whether the traffic between the app and your servers can be read or altered. Whether login can be bypassed, and whether one user can reach another user's data. Whether the app can be repackaged or run on a tampered phone. And the business logic: whether steps can be skipped, amounts changed, or a transaction repeated.

What we will not do

This is a controlled assessment, not a red-team exercise. No phishing, no social engineering, no physical security testing, and nothing destructive or that would take your service offline. We do only the minimum needed to prove a finding is real.

6 How We Rate Findings

SeverityWhat it means
CriticalCould give an attacker full control of an account, the backend, the database or the server, or expose sensitive data at scale. Fix immediately.
HighCould let an attacker take over accounts, reach data they should not see, or gain higher privileges.
MediumA real problem, but it needs certain conditions — a valid login, physical access to the phone, a rooted device, or some user action.
LowLimited impact on its own. Worth fixing as part of normal improvement work.
InformationalAn observation or good-practice suggestion. Not directly exploitable.

Severity considers how easy the issue is to exploit, whether it needs a rooted or jailbroken phone, how sensitive the data is, how many users are affected and the business impact. After a retest each finding is marked Closed, Open, Partially Fixed, Risk Accepted or Not Retested.

7 Timeline Estimate

The build and screen counts are carried over from section 3 automatically.

Timeline inputs

App builds in scope
Screens or pages
Parallel testing teams
Number of retests

An Android build and an iOS build count as two. One retest is included as standard — increase this only if additional retest cycles are required.

Estimated duration 0 working days
Testing0
Retest0

Subject to final scope review, access availability and resource confirmation. The final timeline is confirmed after the complete scope has been reviewed and understood.

Save and Export Response

Your answers stay in this browser until you export or clear them.