A fintech's iOS and Android apps tested against OWASP MASVS, from certificate pinning to API authorization
A financial technology company with about 60 staff and a consumer payments app on iOS and Android, a leader in its segment.
- Scale
- 2 apps (iOS and Android), 1 shared back-end API, about 3 test accounts per role
- Engagement
- 4 weeks of testing and reporting, with a retest two weeks after fixes
The challenge
The company was about to add card controls and money transfers to its mobile apps, and its bank partner asked for independent proof that the apps and the API behind them were safe. Developers had run automated scans, but nobody had tried to attack the apps the way a criminal with a rooted phone would.
A financial technology company was about to add card controls and money transfers to its iOS and Android apps. Its bank partner asked for independent proof that the apps, and the API behind them, were safe. The client is not named on this page, and this is an illustrative engagement that describes the kind of work our team does; details are composite. Testing used a staging environment and test accounts, so no real customer data or money was involved.
The review followed the OWASP Mobile Application Security Verification Standard (MASVS), which lists what a secure mobile app should do, and the OWASP Mobile Application Security Testing Guide, which describes how to check each item. Our team analyzed both app packages statically, then ran them on rooted and jailbroken devices to look for hardcoded keys, leftover debug code and weak tamper checks. Automated scans had passed; this step asked what a person with full control of the phone could do.
Two areas got special attention. The first was certificate pinning, which makes an app trust only its own server's certificate. The testers placed a proxy on a hostile Wi-Fi network and checked what it could read, and what the app did when pinning failed. The second was insecure storage: tokens, cached statements and logs left in app files, backups, the clipboard or screenshots, and whether secrets were kept in the iOS Keychain and Android Keystore rather than in plain files.
The most serious problems were not in the apps. They were in API authorization. By changing an account identifier, calling an endpoint out of order or reusing an old token, a signed-in customer could sometimes reach another customer's data. This is a class of flaw that OWASP's API Security Top 10 calls broken object-level authorization, and a phone-side fix cannot solve it. The fix was a server-side check on every request that the caller owns the object.
Each finding came with reproduction steps, a recommended fix and a retest. After the developers fixed the items, the testers retested them, and the company gave its bank partner a dated report that names what was tested and what was not. This is a technical assessment, not a certification, and a new app release or a major API change calls for a new test.
What our team delivered
- Written authorization and test accounts in a staging environment, so that no real customer data or money was touched
- A review against the OWASP Mobile Application Security Verification Standard (MASVS), using the OWASP Mobile Application Security Testing Guide for the test steps
- Static analysis of both app packages and dynamic testing on rooted and jailbroken devices, looking for hardcoded keys, debug code and weak tamper checks
- A check of certificate pinning and of what a proxy could read on a hostile Wi-Fi network, and of how the app behaves when pinning fails
- A check of insecure storage: tokens, cached statements and logs left in app files, backups, the clipboard and screenshots, and whether secrets sit in the platform keystore
- API authorization testing: whether one customer could read or change another's accounts by changing an identifier, calling an endpoint out of order or reusing an old token
- A report for developers with reproduction steps, fixes and a retest, plus a summary for the bank partner
Result
The company fixed its findings before launch, retested them, and gave its bank partner a dated report that names what was tested and what was not. The most serious problems were on the server side, in API authorization, rather than in the app itself. This is a technical assessment, not a certification.
Get this for your company
Related services with fixed prices and a written scope.
Emergency package: security engineer in 1 hour
Is your company in a cybersecurity crisis? Purchase this package and a security engineer will call you within 1 hour.
Callback within 1 hour, 24 hours a day, 365 days a year
$1,950 per incident
Initial assessment of public endpoints
What an attacker can see and reach from the internet: your domains, mail, websites, remote access and cloud exposure.
Report within 5 business days of kickoff
$1,000 per assessment
Scanning of software codebase
Static analysis and secret detection across one codebase, reviewed by an engineer so you get findings, not noise.
Report within 3 business days of read-only access
$500 per codebase
Show 3 more
Discovery and requirements workshop
Workshops with your team to map every system, process, user group and integration, and to agree what the new platform must do.
Written requirements and a system inventory in 2 to 3 weeks
$6,500 fixed fee
Cloud security review
A review of one Microsoft 365, Azure, AWS or Google Cloud tenant against recognized benchmarks.
Report within 7 business days of read-only access
$2,800 per tenant
Cloud management
We run your Microsoft 365, Azure, AWS or Google Cloud environment: access, cost, patching, backup and security settings. Priced per month for one tenant.
Onboarding within 15 business days
$1,900 per tenant, per month
After you purchase, we contact you within 1 hour, any time of day or night, to start onboarding.
No payment is taken online. When we call you within the hour we confirm the scope and send an invoice (ACH, card or crypto).
Every sign-in, verified
Staff sign in once, but behind the scenes the device, the identity, a phone approval and your access policy are all checked before any app opens, and strangers are turned away.
Attack it before attackers do
Our red team probes your systems the way a real attacker would, and every weakness it finds becomes a fix your defenders put in place and we retest.
Critical patches in days, not months
Distribution of days from vendor patch release to deployment for critical-severity CVEs, before and after a managed patching service. The dashed line marks two weeks: under CISA BOD 22-01, US federal agencies must remediate Known Exploited Vulnerabilities within two weeks for CVEs assigned in 2021 or later (six months for older ones). Private organisations are not bound by it, but it is a sensible benchmark. Illustrative figures.
Facing something similar?
Tell us about your environment. We will tell you plainly what we would do and what it would take.