Mobile APIs are a crucial component of mobile app development, enabling apps to communicate with servers and access data. However, the security of these APIs is often misunderstood, leading to several myths and misconceptions surrounding mobile API security.
We will discuss how HTTPS encryption, API keys, and authentication are not enough to fully secure mobile APIs, and how even private APIs are susceptible to attacks. We will also examine why mobile API security is a shared responsibility among developers, stakeholders, and security teams. Finally, we will explore the misconception that mobile app security is separate from mobile API security, and how both are crucial for protecting users and data.
In this blog post, we will explore these common myths surrounding mobile API security and provide a more comprehensive understanding of the truth behind them. By debunking these myths, we hope to increase awareness of mobile API security and promote best security practices for API developers to achieve robust and resilient APIs in terms of security, where the focus will be more from a perspective of securing access to them, rather than about how to securely code them.
The order in which the mobile API myths are presented below does not carry any significance, so let's examine and debunk some of the most common myths.
Many people believe that using HTTPS encryption is enough to secure APIs. HTTPS is a protocol for secure communication over the internet, which ensures that the data exchanged between the client and server is encrypted and cannot be intercepted or modified by attackers. However, HTTPS encryption alone is not enough to guarantee the security of APIs.
HTTPS encryption is an important aspect of mobile API security. Encryption ensures that data transmitted between the mobile app and the API server is protected from interception by unauthorized parties. Without encryption, sensitive data such as passwords and personal information could be easily intercepted and compromised.
While HTTPS encryption can protect against simple man-in-the-middle attacks and eavesdropping, it does not protect against other types of attacks such as the ones mentioned in the OWAS API Top 10 list. These attacks can compromise the confidentiality, integrity, and availability of APIs, leading to data breaches, unauthorized access, and service disruptions.
Moreover, HTTPS can suffer from SSL/TLS vulnerabilities and with or without them is still vulnerable to MitM attacks when advanced techniques are used, such as a rooted or jail-broken device where custom root certificates can be added. A countermeasure is to use certificate pinning but even so attackers can use an instrumentation framework to disable the pins check at runtime. These advanced attacks used to bypass HTTPS encryption will allow attackers to learn how the mobile and API backend communicate and then exploit vulnerabilities in the API implementation, resulting in security breaches.
For example, the article Bypassing Certificate Pinning illustrates how individuals without programming expertise can intercept HTTPS traffic even when the mobile app implements certificate pinning. All that is required is a willingness to explore new technologies and step outside one's comfort zone, as well as some technical proficiency, like the ones possessed by the users that usually root their own devices for fun or just for customization, not necessarily for malicious activities.
HTTPS encryption is an important security measure for securing APIs, but it is not enough to guarantee their security. API developers should implement additional security measures to protect against various types of attacks and follow security best practices to ensure the confidentiality, integrity, and availability of their APIs. By doing so, they can prevent security breaches and ensure the trust of their users.
API keys are widely used to authenticate what is making the API request and grant access to API resources. They are typically created and managed by the API provider and given to the developers who need to access the API. It is a common misconception that API keys are all the security needed to protect an API that doesn’t require user authentication.
API keys are a critical security measure in API security, but relying solely on them can leave the API vulnerable to security breaches. API keys can be stolen or leaked, and once a malicious user obtains a valid API key, they can use it to access the API and perform unauthorized actions. For example, a hacker can use a stolen API key to gain access to sensitive data or perform operations that were not intended by the API provider.
API keys should be considered as one part of the overall security strategy for an API, but not the only one. To secure an API, it is important to implement other security measures such as encryption, access controls, rate limiting, and monitoring. Additionally, API keys should be treated as secrets and managed securely. This includes measures such as storing them encrypted, rotating them regularly, and revoking them when they are no longer needed.
For example, an attacker can install a mobile app in a device they control and then perform a MitM attack, and this isn’t that hard to achieve as many developers may think. The article Steal That API Key with a Man in the Middle Attack is a good example of how even non-developers can do it, you just need to be a tech savvy person that isn’t afraid of trying out new stuff and going out of the comfort zone.
While API keys are an important component of mobile API security, they are not sufficient to secure a mobile API on their own. Mobile API providers should implement additional security measures to protect APIs from serving requests that aren’t coming from a genuine and unmodified mobile app. Furthermore API keys need to be treated as secrets and not be hard-coded in the mobile app code. Instead they need to be securely retrieved from a remote server, but only delivered to genuine instances of the mobile app that aren’t under attack.
One of the most common misconceptions about mobile API security is that user authentication alone is enough to protect mobile APIs from unauthorized access. While user authentication is certainly an important aspect of mobile API security, it is just one piece of the puzzle, because it only identifies who is in the request, not what is making the request.
Authentication is the process of verifying a user's identity, typically through the use of credentials such as a username and password, OAuth2, magic links, with or without two factor authentication (2FA) involved. This helps to ensure that only authorized users can access the API. However, authentication alone does not provide complete security.
Authorization is another critical component of mobile API security. Authorization is the process of determining what actions a user is allowed to perform once they have been authenticated. This can include access to specific data or functionality within the API. Without proper authorization controls in place, even authenticated users may be able to access sensitive data or perform unauthorized actions.
When both Authorization and Authentication are in place they are still vulnerable to implementation failures and/or security vulnerabilities in the dependencies used. However, the most important factor to keep in mind is that user authentication doesn’t authenticate what is making the request, instead it only identifies on behalf of who is being made. What is making the API request may not be a genuine instance of your mobile, not under a runtime attack, and instead a bot, a manual API request, a replayed or modified request from a MitM attack.
Inadequate authentication measures have led to several high-profile security incidents and breaches, and this is so prevalent that it is at the second position of OWASP API Top 10 2019, and at the current date (April 2023) it continues in the same position at the release candidate for the OWASP API Top 10 2023, which reveals that in four years the API security hasn’t improve that much on this regard, to not say nothing.
While authentication is an important aspect of mobile API security, it is not sufficient on its own. Authorization, encryption, and other security measures must also be implemented to ensure that APIs are protected from unauthorized access and data breaches. Developers and organizations should take an end to end approach to mobile API security, including regular vulnerability assessments, security audits, and employee training to ensure that all stakeholders understand their role in maintaining the security of mobile APIs.
Many developers and businesses assume that since their APIs are not publicly available/documented on the internet, they are inherently secure and cannot be targeted and accessed by hackers. This misconception arises from the assumption that mobile APIs are only accessible by the mobile app that uses them.
Mobile APIs can still be accessed and attacked, even if they are not publicly available/documented on the internet. They can be attacked in a variety of ways, such as via reverse engineering, man-in-the-middle attacks, and session hijacking. Reverse engineering involves decompiling the mobile app and extracting the API keys, which can then be used to access the API directly without the app and potentially steal sensitive data or carry out other malicious activities. Man-in-the-middle attacks involve intercepting and modifying the data transmitted between the mobile app and the API, while session hijacking involves stealing a user's session token and using it to impersonate the user.
Protecting against reverse engineering a mobile app to enumerate their APIs is one of the key challenges of mobile API security. Developers and businesses often think that they can use techniques such as code obfuscation and code hardening to thwart attackers from reverse engineering their mobile applications and access their APIs, but it's proven over and over that this isn't very effective, because attackers will just use a runtime attack to circumvent them, such a MItM attack, that may or require the use of an instrumentation framework to bypass certificate pinning, if in use. Other attack vectors to consider when securing mobile APIs include brute-force attacks and injection attacks, but not limited to only these ones.
For example, in the article How to MitM Attack the API of an Android App you can have an idea of how an attacker can launch a MitM attack on the mobile app to know which APIs the mobile app communicates with and to understand how the requests are made and which responses to expect to then use this knowledge to build an attack strategy, be it with a bot or with manual request from cURL or Postman. At the end of the day your mobile API isn’t anymore private.
But my API is really private, it’s in an internal network, not accessible from the outside. Did you consider that the attacker can be one of your trusted users? Or that an attacker was able to get physically inside your installations, therefore with the potential to access a mobile device from where he can launch the attack? Don’t be surprised, it happens.
It is important to recognize that mobile APIs can still be targeted by attackers even if they aren’t publicly available/documented or if they are indeed in a private network. It is crucial to implement additional security measures, such as dynamic certificate pinning and remote mobile app attestation to protect against these attacks. Regular security testing and vulnerability assessments should also be conducted to ensure that mobile APIs remain secure.
One of the most common misconceptions surrounding mobile API security is that it is solely the responsibility of the security team. While the security team does play an important role in securing mobile APIs, it is not their sole responsibility. Instead, mobile API security is a shared responsibility that involves different teams and stakeholders, including developers, operations, and business leaders.
Developers play a critical role in mobile API security. They must follow best practices, use secure coding practices, and test their code regularly to identify and address vulnerabilities. They must implement security controls such as encryption, access controls, and input validation to ensure that the API is not vulnerable to attacks.
Product owners are responsible for establishing security requirements and guidelines for developers to follow. They must also ensure that the API is tested for security vulnerabilities before it goes live.
Business leaders also have a role to play in ensuring mobile API security. They must prioritize security by allocating the necessary resources, establishing clear security policies, and ensuring that everyone in the organization understands the importance of mobile API security.
Finally, the security team is responsible for monitoring and responding to potential security incidents. They must also work with other teams to ensure that the API is kept secure and compliant with industry standards and regulations.
Mobile API security is a shared responsibility that requires collaboration between different teams and stakeholders. A lack of collaboration and communication between teams can lead to security gaps and vulnerabilities that hackers can exploit.
By involving each team in the mobile API security process, organizations can ensure that everyone has a stake in the security of the API, and security becomes an essential aspect of the development process and posterior maintenance of the mobile app and API, which includes bug fixes, new features and to keep the API running securely while having realtime visibility for threats on the mobile app that can result in an API attack and consequent risk of a data breach.
Developers, business leaders, and security teams must work together to ensure that mobile APIs are secure and protected against cyber threats. By prioritizing the use of end to end mobile API security and implementing best practices, businesses can protect their sensitive data and customer information from cybercriminals. Neglecting any aspect of security can lead to significant security incidents, as seen in recent examples of API breaches.
One common myth about mobile API security is that it only matters for high-risk industries such as finance, retail, healthcare, and government. This myth assumes that other industries, such as gaming or entertainment, don't need to prioritize mobile API security because they don't handle sensitive or confidential information. However, this is a dangerous assumption because all mobile APIs are potential targets for hackers, regardless of the industry.
Mobile API security is not just important for high-risk industries. Hackers are opportunistic and will target any organization that has a vulnerability they can exploit. Mobile APIs are a common target for attackers because they often contain sensitive data and can provide a way to access an organization's internal systems. Neglecting mobile API security can lead to significant financial and reputational damage, as well as legal liability.
While some industries may have more valuable data or more regulations around data privacy, attackers are constantly looking for vulnerabilities in any system they can access. In fact, smaller businesses and startups may be more vulnerable to attacks because they often have limited resources to devote to security.
Smaller businesses and startups may feel that they can't afford to prioritize mobile API security, but the cost of a security breach can far outweigh the cost of implementing proper security measures. Hackers may use small businesses as stepping stones to larger targets, and even a small data breach can damage a business's reputation and result in lost customers.
For example, this article from 2022 has several examples of businesses that file for bankruptcy after a data breach.As seen in the article, security breaches have occurred in other industries, not only on the usual targets: retail, healthcare, and finance. These incidents show that mobile API security is essential for all industries, regardless of the sensitivity of the data they handle. Even small businesses and startups can be targets for hackers, and neglecting mobile API security can lead to devastating consequences.
The lesson to take is that small businesses have limited resources to cope with and to recover from a security breach when compared with big companies.
Mobile API security is a critical aspect of overall security and should not be overlooked or underestimated. All mobile APIs are potential targets for hackers, and even small businesses and startups should prioritize implementing proper security measures to prevent security breaches. It is crucial to involve all stakeholders, including developers, security teams, and business leaders, in building a culture of end to end mobile API security.
One of the common misconceptions about mobile API security is that it is independent from mobile app security. This is often due to the perception that mobile app security can only be addressed separately from their API counterparts. This perception is reinforced and augmented by the fact that security solutions always tend to solve the security needs of each in isolation.
In fact, mobile app security and API security are closely related and should be treated as part of the same security ecosystem. Mobile apps typically rely on APIs to communicate with back-end servers, and any vulnerabilities in the mobile app can expose the mobile API to security risks and allow attackers to conduct successful attacks.
An attacker will often reverse engineer a mobile app or perform a runtime attack to extract the required secrets to call the mobile API outside of the mobile application. Similarly, if the API is not properly locked down to only accept requests from genuine and unmodified instances of the mobile app, not under attack, then an attacker can use that security gap to gain access to the APIs data from a bot or simply by sending one of API requests from a terminal.
For example, when a mobile is under a MItM attack, where the attacker can modify and replay the requests, the API backend will not be aware of such attacks are occurring and will continue to serve the API requests as if they were coming from a genuine instance of the mobile that isn’t under attack, which isn’t the case anymore.
So, the question is how do you gain real time visibility to the attacks going on on the mobile app to be able to decide when to refuse to fulfil API requests you cannot trust in the origin?
The answer is that you need an end to end security solution that is able to continuously perform a remote mobile app attestation of the app and device integrity, and have a mechanism to let the API backend know when this integrity has been compromised.
Mobile app security and mobile API security are interdependent and should be treated as a whole. Developers should prioritize both components' security by implementing best practices, applying access control measures, and continuously monitoring for vulnerabilities, while having an end to end security solution that secures both the API backend and the Mobile App in one single product. By doing so, they can ensure their app and API are secure against potential attacks started in the mobile app or outside of it, thus safeguarding user data and protecting their business from reputational damage and financial loss.
Mobile app security shouldn’t be treated as a separate concern from mobile API security, but rather as a part of an end to end security strategy.
As we have seen, there are several myths and misconceptions surrounding mobile API security that can leave them exposed to attacks via the mobile applications that consume them. From relying solely on HTTPS encryption to thinking that mobile APIs are immune to attacks, these myths can lead to serious security breaches.
Therefore, it is crucial to understand the reality of mobile API security and take appropriate measures to protect mobile applications against potential threats. This can involve implementing additional security measures beyond authentication and API keys, involving all stakeholders in mobile API security, and recognizing that mobile app security is not separate from mobile API security.
By dispelling the myths surrounding mobile API security, developers and businesses can now understand the need to use end to end security to protect their APIs and mobile applications against security threats and ensure that both the APIs and the mobile apps using them remain a safe and convenient way to access services and information on-the-go. It is important to stay vigilant and informed about mobile API security risks, as the landscape is constantly evolving, and new threats are emerging every day. It’s not enough to keep up to date, to be vigilant mobile app developers must have real time visibility of the threats faced by their mobile apps so that they can keep the mobile API secure from potential attacks that will steam from the mobile application being under attack.
Paulo Renato is known more often than not as paranoid about security. He strongly believes that all software should be secure by default. He thinks security should be always opt-out instead of opt-in and be treated as a first class citizen in the software development cycle, instead of an after thought when the product is about to be finished or released.
