SysTools logoSysTools VAPT
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 10. 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.

4 Backend and APIs

Mandatory

Most serious mobile findings are in the backend the app talks to, not the app itself.

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.

Pinning stops us reading the app's traffic. We can usually work around it, but it is much faster if you can give us a build with it switched off.

A lot of mobile testing has to be done on a rooted or jailbroken phone. If the app blocks that, tell us so we can plan for it.

5 Access and Login

Needed before we can start

Without a login for each role we cannot check whether one user can reach another user's data — the most common serious finding.

Two accounts in the same role let us prove whether one user can see the other's data.

If OTPs go to a phone number we do not control, testing stalls every time we need to log in.

6 Test Environment and Restrictions

Mandatory

Anything you do not allow here will not be tested.

If it stays on and keeps blocking us, the report ends up describing the firewall instead of the app.

What is included as standard

Every Mobile Application VAPT includes taking the app apart and reading it (static analysis), running it on a test device and watching what it does (dynamic analysis), checking what it stores on the phone, checking how it talks to your servers, login and permission checks, business logic testing, and controlled follow-up on anything we confirm as a real issue. You do not need to select these.

This is a controlled assessment limited to the scope you approve, not a red-team exercise. It does not include phishing, social engineering, physical security testing, or attempts to stay hidden inside your network.

7 Data and Standards

Affects how serious a finding is

8 What We Will Test

All included by default

Everything below is included. Untick anything you want left out. Based on the OWASP Mobile Application Security Testing Guide.

9 How We Run the Assessment

A mix of automated tools and manual testing, adjusted to your app, the platforms in scope, the roles available and the access you provide.

01

Confirm scope and access

We agree the app builds, platforms, versions, environment, user roles, login details, device requirements, testing dates and any restrictions, and confirm written authorization before starting.

02

Gather information

We look at the app package, its version, permissions, exported components, deep links, third-party libraries, backend endpoints and signing details.

03

Static analysis

We take the app apart without running it — the manifest, resources, decompiled code and native libraries — looking for hardcoded keys, insecure settings and vulnerable libraries.

04

Dynamic analysis

We run the app on a test device or emulator and watch what it actually does: login flows, session handling, logs, clipboard, screenshots, background behaviour and network traffic.

05

Local storage and network testing

We check what the app keeps on the phone and whether it is protected, then check that traffic to your servers uses HTTPS properly and validates certificates.

06

Login, permission and API testing

Login bypass, token handling, whether one user can reach another user's data, and the checks the backend does — or fails to do — on every request.

07

Tampering and business logic

We check whether the app can be repackaged, hooked or run on a rooted phone, and whether normal features can be misused: skipping steps, changing amounts, repeating transactions.

08

Confirm each finding

We reproduce every issue, note the affected app version, platform and role, and capture evidence. We use the least intrusive method that proves the problem, and avoid anything destructive.

09

Report and retest

Each finding is rated and written up with clear fix guidance. Once you have released a fixed build, we retest against it and update the status.

Anything urgent is reported immediately

If we find something serious — a login bypass, admin account takeover, hardcoded production credentials, private keys in the app, or access to all customer records — we tell you straight away rather than waiting for the final report.

Standards we work to

OWASP Mobile Application Security Testing Guide (MASTG), OWASP Mobile Application Security Verification Standard (MASVS), OWASP Mobile Top 10 and, where the backend is in scope, the OWASP API Security Top 10. Severity uses CVSS, weaknesses are classified with CWE, and CERT-In guidance is applied where it is relevant to you.

10 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.

11 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.