Mobile app testing
Mobile application penetration testing, device to backend.
A tester examines what the app stores on the device, what it sends over the network and what the backend it calls will accept.
What a tester checks on your mobile app.
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.jsonKeys 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/sessionTraffic to your servers
Whether the app refuses a certificate it has no reason to trust.
For example, acme-corp.com:443See the sample findingLinks and other apps
Links, shared files and messages from other apps that open your screens.
For example, acme://ordersWhat the build gives away
Keys, hidden endpoints and debug switches anyone can read in the build.
For example, assets/config.jsonChanged 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.
How we test it, step by step.
On test devices, one layer at a time: what the app stores, what the build reveals, what the traffic carries, then the backend.
A tester leads every step. AI speeds up recon, triage and reporting, and a person reviews every finding before it reaches you.
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.
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.
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.
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.
Three attack paths, one from 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.
One sample finding, in full.
What we did, what came back, what it means for the business and the fix, written for the team that owns it.
Acme Corp is a fictional client. Every sample on this page is illustrative, never client data.
Release build accepts untrusted TLS certificates
Whereapi.acme-corp.com/v2/login
Sign in through a test proxy
proxy cert: self-signeddevice trust: not installed
What the proxy saw
POST /v2/login HTTP/1.1Host: api.acme-corp.compassword=[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.
What lands on your desk.
Each fix is marked for the app or the backend, so your mobile and server teams each pick up their own work.
Report
Findings, proof and fixes
Fix guidance
Each fix marked for the app or the backend
Executive briefing
What each layer exposes, in business terms
One retest within 30 days of the report
Certificate checks now enforced
Who it suits, and when to book it.
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 apps.
Testing follows these standards, so your team can read the method against references it already uses.
NIST SP 800-115
National Institute of Standards and Technology (NIST) Special Publication 800-115
The technical guide to information security testing and assessment.
CWE Top 25
Common Weakness Enumeration (CWE) Top 25
The most dangerous software weaknesses, listed by MITRE.
OWASP ASVS
Open Worldwide Application Security Project (OWASP) Application Security Verification Standard (ASVS)
Security requirements an application is verified against, in three levels.
Aligned with, never certified by. Names belong to their owners; no endorsement implied.
Questions before scoping.
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.