They use it to log in, sign transactions and confirm payments. If an attacker controls their phone, or gets your backend to accept a tampered app, they can act in your customer's name. The same attack that works against your app works against every customer who has it installed.
Mobile app security for banking and fintech.
Your app moves money, so attackers go straight at it: fraud running on your customers' phones, and your backend tricked into trusting a tampered app. We test it the way that fraud actually works, and give you the report your PSD2 and DORA obligations call for.
To your customers, the app is the bank.
How attackers turn your app into fraud.
- Overlay and accessibility abuse: malware reads the screen, captures credentials and taps buttons on the customer's behalf.
- Device and session cloning: moving a customer's keys or session to another phone and transacting from there.
- Tampered apps: bypassing root, jailbreak or instrumentation detection to change what the app does, such as the amount or the payee of a transfer.
- Automation: signing up or logging in at scale with bots and fake devices.
The weaknesses behind account takeover.
In banking and fintech apps, account takeover keeps coming back to the same technical weaknesses. These are what we go after.
- Insecure token or session storage: session tokens left in plaintext preferences, logs or backups, where another app or anyone with the phone can read them.
- WebView and JavaScript bridges: authentication tokens exposed to content loaded in a WebView, or reachable from a JavaScript bridge.
- Deeplink hijacking and intent redirection: a malicious app registering the same links, or relaying intents, to intercept OAuth callbacks and authorization codes.
- Hardcoded secrets: API keys and credentials left in the app binary, extractable by anyone who downloads it.
- Weak device and biometric binding: a session that still works on another device, or a biometric prompt not bound to a key, so it can be skipped.
- Broken API authorization: one customer reading or moving another customer's money by changing an identifier in a request.
You can see several of these worked through end to end on a deliberately vulnerable app in our sample report.
Services for your app.
Mobile app penetration testing
We look for ways to steal from your customers through your app and its API: device binding, authorization and data on the phone.
App protection testing
Does your app detect root, instrumentation or malware that abuses accessibility? We check whether those protections stop an attacker.
The standards that apply to you.
Banking apps fall under several standards and regulations. We cover the mobile side of each: some we report on directly, others we get you ready for the lab.
PSD2
Testing of your strong customer authentication, as evidence for the independent audit.
DORA
Independent yearly testing of the apps behind your critical or important functions.
PCI DSS
Application-layer penetration testing of your app and its API for requirement 11.4.
PCI MPoC
The vulnerability assessment and penetration test required before your PCI MPoC laboratory evaluation.
Pre-evaluation for an accredited labGDPR
Testing the effectiveness of your security measures under Article 32.
CRA
Security test reports for your Cyber Resilience Act technical documentation.
Why vulnit for banking and fintech.
We have been evaluators
Our team comes from security certification laboratories, with experience in mobile payment standards such as EMVCo SBMP and in Common Criteria.
We test your protections the way an attacker would
Our team contributes to MASVS-RESILIENCE, the part of OWASP MAS that covers platform integrity and resistance to debugging, tampering, reverse engineering, emulators and dynamic instrumentation. OWASP recognized this work by naming vulnit an OWASP MAS Advocate.
Our own technology
Chameleon gives us deep visibility into what your app does inside the operating system, which makes the analysis faster and more thorough. The controls that usually slow testing down, such as root, pinning and anti-instrumentation checks, are handled at the OS level by default, so our time goes into finding issues in your app instead of getting past them.
Meet the teamBanking mobile security frequently asked questions.
How often do I need to test my app?
DORA requires applications that support critical or important functions to be tested at least once a year. If your app is part of the cardholder data environment, PCI DSS calls for a penetration test at least once a year and after significant changes. The PSD2 technical standards require strong customer authentication measures to be tested periodically.
Does your testing work for DORA and for the PSD2 audit?
DORA requires tests to be performed by independent parties, internal or external; we are an external, independent team, and the report sets out the scope, the tests and the results. For PSD2, the strong customer authentication measures must be tested and then audited by an independent auditor. The audit checks that the measures are adequate and have been tested: the auditor reviews the evidence rather than running the test, so our report serves as that evidence.
Can you test an app with certificate pinning, root detection or RASP?
Yes. Getting past those protections is part of our daily work, and with Chameleon, our own Android, it is handled at the operating-system level by default, so those checks do not get in the way of the analysis. If you also want to know whether your protections stop an attacker, we check that in app protection testing.
Do you test iOS as well as Android?
Yes. We test both, to the same depth. On Android we work with Chameleon; on iOS we test on physical devices. If your app runs on both platforms, we deliver one report per platform.
Are backend APIs included?
They can be, and we generally recommend it: much of a mobile app's risk lies in the APIs it uses. We decide it with you case by case, depending on the type of app and what its backend exposes.
Do you need source code?
No. By default, testing is black-box: we attack your app with the same information an attacker would have, using the same build you release to your users. DORA includes source code reviews among its tests, where feasible. If you share the code, we review it too.
Can I combine several services in one project?
Yes. They all start from the same analysis of your app. Tell us what you want to know, for example which vulnerabilities it has, whether your protections stop an attacker or which OWASP MASVS controls it meets, and we combine it into a single project.
How do you handle confidentiality?
We agree confidentiality terms before you share builds or documentation. We have a standard NDA, but if you prefer to use yours, we are happy to review it.
Need to test your app this year?
Tell us about your app and the standards you need to meet. We reply within one business day to arrange a scoping call.
Talk to our team