Smartphone as a Target: Who Is Responsible When a Mobile App Is Hacked?

Imagine this scenario: a user downloads your app, enters their card details, taps "Pay" - and three days later discovers that their bank account has been drained. They didn't click on any suspicious links, didn't respond to phishing emails, and simply used your product.

Who is to blame? The uncomfortable answer is: most likely, the app owner.

From our own experience, we know that mobile cybersecurity is one of those topics that startups and product owners unfortunately tend to put off until "later." First comes the MVP, then user acquisition, then monetization, and somewhere far down the backlog sits a ticket that says, "deal with security." But cybercriminals don't wait for you to be ready.

A smartphone is the most convenient target

Today, a smartphone is a wallet, a passport, a diary, and a house key all in one device. It is always connected to the internet. It is always with us. And it contains dozens of apps, each with access to different parts of our digital lives. This is why mobile devices have become one of the most common entry points for cyberattacks.

In our opinion, however, it is important to distinguish between two types of threats: those for which the user is responsible and those for which the mobile product owner is responsible.

There is the user's domain, and there is the mobile app's domain. The two should not be confused.

When the user is responsible

If someone receives an SMS from their "bank" asking them to follow a link and verify their card, and they do so, that is phishing. It is a user error. As the owner of a mobile app, you cannot prevent someone from opening the door to scammers.

An analogy: if someone opens the door to a stranger claiming to be a plumber, and that person steals the TV, it is not the fault of the manufacturer of the front door lock.

When the mobile app owner is responsible

Now consider a different situation: the user did not click on anything, did not do anything suspicious, but their data was leaked from your server. Or your SDK transmitted tokens in an unencrypted format. Or an attacker was able to tamper with your API response because of an unpatched vulnerability.

This is no longer a user error. It is a systemic flaw in your product. And the party responsible for it is the owner of the mobile app - legally, reputationally, and often financially.

This is where the line is drawn: if the threat comes through the app, the responsibility shifts to its owner. That is why the importance of cybersecurity for business is difficult to overstate.

What can ignoring mobile app cybersecurity lead to

In many cases, we have seen startup founders believe they are too small to be targeted by hackers, assuming that cybercriminals are only interested in large banks and corporations.

But this is a misconception held by those who do not understand what cyberattacks are. In reality, small products are ideal targets precisely because they are less protected. Automated scanners do not distinguish between a startup and an enterprise - they search for open ports, vulnerable libraries, and unencrypted tokens regardless of the size of the company. There are dozens of types of cybersecurity vulnerabilities, and each one can become a potential entry point for an attacker.

The cost of such a mistake is high: a single serious incident can cause you to lose user trust, face regulatory investigations (especially if you process personal data or payments), or even force you to shut down your business altogether.

This is clearly illustrated by one of Datami's cases. A technology company approached us while preparing its mobile app for release and wanted to verify that it contained no critical risks before going to market. During a penetration test that included elements of reverse engineering, the Datami team examined the app's authorization logic, data processing, API, and internal components. As a result, critical and medium-severity vulnerabilities were identified that could potentially have led to the leakage of confidential information or unauthorized access.

This case demonstrates an important point: dangerous vulnerabilities do not necessarily appear only in "mature" products after years on the market. They can be built in even before release - in the authorization logic, API, error handling, or data validation. And if they are not identified during mobile security penetration testing, then after launch, they become not just a technical flaw, but a real business risk.

What you need to do to protect mobile apps

Here's what we recommend to mobile product owners:

1. Secure the data transmission channel

All traffic between the app and the server must go exclusively through HTTPS with valid certificates. But even that is not enough - implement SSL Pinning. This prevents an attacker from substituting a certificate and intercepting data even on a secure network.

An analogy: HTTPS is like an armored front door, while SSL Pinning is an additional check that the person behind the door really is who they claim to be.

2. Don't store more than necessary on the device

Minimize the amount of data that remains on the user's smartphone. If data must be stored, use Keychain (for iOS) or Keystore (for Android), rather than plain unencrypted SharedPreferences or a local database without encryption. Tokens, passwords, and session keys should either be stored in secure storage or not stored at all.

3. Implement proper authentication

• Mandatory MFA for sensitive actions (changing a password, large transactions, changing an email address).
• Short token lifetimes and mandatory invalidation after logout.
• Protection against brute-force attacks: rate limiting, CAPTCHA, or temporary account lockout after N failed attempts.
• Never store passwords in logs - it may sound obvious, but we encounter this very often.

4. Check third-party libraries and SDKs

A mobile app is more than just code. It consists of dozens of dependencies: analytics, advertising, payments, and push notifications. Every library is a potential entry point.

Regularly update your dependencies. Check them using OWASP Dependency-Check or similar tools. If an SDK hasn't been updated in two years, that's a reason to replace it or at least perform a thorough security review.

In practice, we often see that the weak point is not only in the app's code itself, but also in the environment where it runs: containers, network communication, configurations, dependencies, and supporting services. For example, during a white-box penetration test of servers running in Docker containers for a software development company building medical, financial, and real estate products, the Datami team identified nine vulnerabilities related to the risk of database access through inter-container communication. This example clearly illustrates that even if the mobile client appears to be secure, the backend, container environment, SDKs, libraries, and API integrations also need to be tested regularly.

5. Secure the API layer

Mobile app attacks often occur not through the app itself, but through the API. Check the following:

• Are all endpoints protected by authentication?
• Is rate limiting enabled for critical routes?
• Does the API return more data than the client actually needs (over-fetching)?
• Do you log anomalous activity, and do you have a response process in place?

6. Teach your team to think about security

Security by design means that a developer, while planning a feature, is already thinking: "What vulnerability could arise here?" This is not an innate quality; it is a skill.

Responding to security incidents is more expensive than investing in training your team.

7. Conduct regular security assessments

Mobile app cybersecurity is not a one-time activity - it is an ongoing process. At a minimum, once a year (after updates or before every major release), we recommend conducting:

• Penetration testing – an external team performs a controlled simulation of an attack against your product.
• SAST/DAST code analysis – automated detection of vulnerabilities in the source code and while the application is running.
• App permission review – verifying that the app requests only the permissions it genuinely needs.

What is mobile application penetration testing, and how does it work?

Mobile application penetration testing is a safe and controlled simulation of a real attack on your app, carried out by a team of cybersecurity specialists.

The goal of a penetration test is to identify all weaknesses in your security so that attackers have no opportunity to exploit them.

We recommend conducting this type of cybersecurity assessment on a planned basis once a year, as well as before every major release or after significant architectural changes. Threats evolve constantly, even if your app's code remains unchanged. That is why pentesting should be performed at least once a year, regardless of whether any changes have been made.

What is checked during a mobile application penetration test

1. Client-side: how data is stored, whether sensitive information is exposed in plain text, and how well the code is protected against reverse engineering.
2. Network communication: whether traffic between the app and the server can be intercepted, whether SSL Pinning is implemented correctly, and whether all API requests are properly secured.
3. Authentication and authorization: whether login can be bypassed, unauthorized access to other users' data can be obtained, or session tokens can be abused.
4. Business logic: whether there are ways to manipulate the app's functionality - for example, changing the amount of a transaction or gaining access to restricted features.

What the process looks like

First, the specialists gather information about the application and identify its attack surface. Next comes the active phase of mobile application penetration testing, using both manual and automated techniques. Once the assessment is complete, the client receives a detailed report that includes:

• a list of the identified vulnerabilities with their severity levels;
• an explanation of how each vulnerability could be exploited;
• specific recommendations for remediating the security issues.

If our penetration testers identify critical vulnerabilities, we provide a free retest after they have been fixed.

What the mobile app owner receives

After the mobile application penetration test, the client receives more than just a list of identified issues - they gain a complete picture of the actual security posture of their product. They know exactly where the vulnerabilities are, how critical they are, and what needs to be fixed - without guesswork or assumptions that "everything seems fine."

A penetration test report is essentially a clear action plan: what should be remediated first, what can wait, and how to build security that will remain effective in the long term rather than only until the next release.

An additional benefit is that the penetration test report serves as a document of trust. For investors, enterprise clients, and business partners, an independent security assessment is increasingly becoming a mandatory requirement before starting a business relationship.

Most importantly, every dollar spent on a penetration test today can potentially save tens of thousands tomorrow. Recovering from a cyber incident, compensating users, and dealing with reputational damage all cost significantly more than carrying out a preventive security assessment.

Conclusion

Today, a mobile application has access not only to a user's screen, but also to their money, documents, contacts, messages, and personal data. That is why any vulnerability is more than just a technical flaw - it is a direct risk to the user and to their trust in your product.

When a data breach, financial theft, or account compromise occurs through an application, responsibility is rarely viewed as something abstract. Users expect that the product they entrusted with their data has been properly secured. And if the incident was made possible by weaknesses in the application, explanations such as "the user should have been more careful" or "attackers cannot be stopped" are no longer sufficient. Responsibility shifts to the product owner who released the application without an adequate level of security.

The good news is that most mobile application vulnerabilities can be identified and fixed before an attacker has the opportunity to exploit them. That is exactly why mobile application penetration testing exists, not as a formality or simply to satisfy auditors or investors, but as a real assessment of how well a mobile application is prepared to withstand an attack.

Are you ready to be the first to discover the vulnerabilities in your digital asset?

Terms we used in this article