Skip to content
Request a quote

Every test includes

  • Proof of exploit for every finding
  • An executive briefing for leadership
  • One retest, within 30 days of the report
Request a quote

Questions first?info@greysurface.com

Mobile application penetration testing, from device to backend

GreySurface mobile application penetration testing traces your app from the phone to your servers. It shows what a lost device, a hostile network or a copied build could reach.

Request a quote, Mobile appSee a sample finding

What does a mobile app penetration test cover?

The four places your users' data lives: the app on the phone, what it stores there, the traffic it sends and the backend it calls.

  • Data stored on the device

    Tokens, personal data and logs left in app files, caches and backups.

    For example, files/session.json

  • Keys and encryption

    Where the app keeps its keys, and whether stored data stays protected.

  • Sign-in and sessions

    How tokens are issued, refreshed and ended when a user signs out.

    For example, POST /v2/session

  • Traffic to your servers

    Whether the app refuses a certificate it has no reason to trust.

    For example, acme-corp.com:443See the sample finding

  • Links and other apps

    Links, shared files and messages from other apps that open your screens.

    For example, acme://orders

  • What the build gives away

    Keys, hidden endpoints and debug switches anyone can read in the build.

    For example, assets/config.json

  • Changed copies of the app

    How far a modified copy of your app gets against the backend.

  • The APIs behind the app

    Each backend call made directly, with the app taken out of the way.

    For example, GET /v2/orders/{id}

What we need from you

  • An installable build of the app
  • Test accounts for each kind of user
  • Where the backend is hosted

On live systems

Live systems by default, inside agreed windows, with a named contact and no destructive actions.

Four layers, tested in the order an attacker works

On test devices, one layer at a time: what the app stores, what the build reveals, what the traffic carries, then the backend.

  1. Map the app's calls

    What the tester does

    We install the build on test devices, use every screen and record each call it makes.

    What you learn

    Which hosts, endpoints and third-party services the app talks to.

  2. Read what the phone keeps

    What the tester does

    We sign in, use the app as a customer would, then examine what it leaves in storage.

    What you learn

    What a lost, shared or backed-up phone would give away about your users.

  3. Open the build and traffic

    What the tester does

    We review the build and pass its traffic through our own test proxy.

    What you learn

    Which secrets ship inside the app, and whether its traffic can be read.

  4. Call the backend directly

    What the tester does

    We send the app's requests ourselves, as other users and with the app set aside.

    What you learn

    Whether your servers enforce each rule, or trust the app to enforce it.

A tester leads every step. AI speeds up recon, triage and reporting, and a person reviews every finding before it reaches you.

Three attack paths, one for each layer

Each sample starts at a different layer: a lost phone, the published build and a request sent without the app.

  • Sample

    A lost phone keeps its session

    A finder copies the stored session off a lost phone. Your backend answers them as the customer.

  • Sample

    A key shipped inside the build

    The store build holds a live messaging key. A stranger lifts it and texts your customers as you.

  • Sample

    The backend trusts the app

    The app shows customers only their own orders. The same request, sent without the app, returns anyone's.

Sample finding: a release build that trusts any certificate

What we did, what came back, what it means for the business and the fix, written for the team that owns it.

A sample fromTraffic to your servers
Sample: Acme CorpCWE-295High

Release build accepts untrusted TLS certificates

Whereapi.acme-corp.com/v2/login

Proof of exploit

Sign in through a test proxy

proxy cert: self-signed
device trust: not installed

What the proxy saw

POST /v2/login HTTP/1.1
Host: api.acme-corp.com
password=[redacted]
Business risk
Someone on a shared Wi-Fi network could read a user's password and session as they sign in.
Fix
Remove the debug trust setting from release builds and keep the platform's certificate checks.

Removed: trustAllCertificates: true,

Added: trustAllCertificates: false,

Checked by a tester before it reached the report.

Separate fixes for your app and backend teams

Each fix is marked for the app or the backend, so your mobile and server teams each pick up their own work.

what you receiveSample

  1. Report

    Findings, proof and fixes

  2. Fix guidance

    Each fix marked for the app or the backend

  3. Executive briefing

    What each layer exposes, in business terms

  4. One retest within 30 days of the report

    Certificate checks now enforced

Built for apps that hold sessions and sensitive data

Teams whose app signs people in, keeps a session on the phone or carries payment or health data to a backend you run.

  • Consumer apps

    Apps that sign people in and keep a session on the phone.

  • Fintech and health

    Apps carrying payment or patient data between the phone and your servers.

  • Companion apps

    A mobile front end on the same API your web app uses.

When to book it

  • Before a store releaseTest the release build before it reaches your users' phones.
  • After a sign-in changeNew biometrics, single sign-on or token handling change what the phone holds.
  • For a customer security reviewA buyer's questionnaire asks for a recent mobile test with proof behind it.
  • Before you add paymentsPayments or health records raise what one leaked session is worth.
  • After a rebuild or new frameworkA new framework changes how the app stores data and checks certificates.

Aligned with NIST, CWE and ASVS for mobile

  • NIST SP 800-115

    Technical guide to security testing and assessment

  • CWE Top 25

    The most dangerous software weaknesses

  • OWASP ASVS

    Application Security Verification Standard

Aligned with, never certified by. Names belong to their owners; no endorsement implied.

Scoping a mobile app test

We reply to every quote request within one business day, from info@greysurface.com.

How is the scope of a mobile test agreed?

In a scoping conversation before we quote. We agree the builds, user roles and backend hosts across the app, what it stores, its traffic and the APIs it calls.

Is the app tested by a person?

Yes. A tester leads every part of the test. AI helps sort the surface first, and a person reviews every finding before you see it.

Will testing disrupt our live app or users?

We test live systems by default, inside agreed windows, with a named contact and no destructive actions. We sign in with the test accounts you give us.

What do you need from us to test the app?

An installable build, test accounts for each kind of user and where the backend is hosted. Tell us which platforms you ship.

Do you test the backend APIs the app calls?

Yes. We call your backend directly, with the app set aside, to see what a request the app would never send can reach.

Is a retest of the app's fixes included?

Yes. One retest of the findings we reported is included, within 30 days of the report. We check app fixes in your new build and backend fixes on the server.

What do our app and server teams receive?

A report with proof of exploit, the business risk and a fix for every finding, each marked for the app or the backend. Leadership receives an executive briefing.

The stack behind your app

All penetration test types, side by side

Ship the app tested. Phone to server.

Tell us which platforms you ship and where your backend runs.

Request a quote