Saved cards, loyalty points, coupons and addresses. An attacker who gets into your customer's account or automates your app turns all of it into money. The same attack that works against your app works against every customer who has it installed.
Mobile app security for retail and e-commerce.
Your app holds saved cards, loyalty points and customer data, so attackers go after the accounts that hold them: account takeover, loyalty and refund fraud, and bots that buy up your stock. We test it the way that fraud actually works, and give you the evidence to back your PCI and data-protection obligations.
Everything your app stores has value.
How attackers turn your app into fraud.
- Account takeover: trying leaked passwords at scale, or reusing a customer's session to spend their points or buy with their saved card.
- Loyalty, points and refund fraud: redeeming points that are not theirs, duplicating coupons, or forcing refunds and returns the rules should not allow.
- Payment abuse: changing prices, quantities or amounts in a tampered app or request, and getting the server to accept them.
- Bots and scalping: automating sign-up, login or checkout to buy up limited stock before your customers can.
- API abuse: reaching another customer's orders, addresses or points by changing an identifier in a request.
The weaknesses behind account and loyalty fraud.
In retail and e-commerce apps, fraud 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.
- Broken API authorization: one customer reading or changing another customer's orders, addresses or points by changing an identifier in a request.
- Client-trusting logic: prices, discounts, quantities or loyalty balances the server accepts from the app instead of recomputing them on its own.
- Hardcoded secrets: API keys and credentials left in the app binary, extractable by anyone who downloads it.
- Weak device binding: a session or a saved payment method that still works once it is copied to another device.
You can see several of these worked through end to end on a deliberately vulnerable app in our sample report.
Services for your app.
The standards that apply to you.
Where your app handles payments or personal data, you are expected to test it and keep the evidence. We cover the mobile side of each standard: some we report on directly, others we get you ready for the lab.
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 labPSD2
Testing of your strong customer authentication, as evidence for the independent audit.
GDPR
Testing the effectiveness of your security measures under Article 32.
Why vulnit for retail.
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 teamRetail mobile security frequently asked questions.
Do you use my customers' real accounts?
No. We only use accounts you provide or that we create ourselves, never other real users' accounts.
Can you test in a test environment?
Yes. We test in the environment you prefer, whether production or a test environment. The proposal sets out the details.
What if I already have an anti-bot solution?
We check whether it stops an attacker in your app, with your configuration. You receive every confirmed bypass, with its impact and the steps to reproduce it.
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. If you prefer, we can also review the source code.
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.
Can your app stand up to bots and fraud?
Tell us about your app and what you want to prevent. We reply within one business day to arrange a scoping call.
Talk to our team