Michael Isbitski, technical evangelist at Salt Security, identifies three reasons why organisations are still failing at API security
APIs have come a long way. Gone are the days of limited use; in fact, recent data has shown over a quarter of businesses have doubled API usage in the past year, with 5% saying they have more than tripled their APIs. This increase amplifies the risk of attacks which, according to the same study, have risen nearly 700% in the same time period. Modern APIs expose more sensitive data than ever, making them a valuable target.
While organisations have wised up to the need for increased API security, several key barriers to success persist.
Scaling API management for long-term growth
Insufficient awareness
Organisations lacking sufficient awareness and visibility into their attack surfaces will struggle to accept the risk that APIs pose. When it comes to recognising the security threat that APIs present in their environment, most organisations fall into one or more of the common misconceptions:
- “We know all our APIs” – Most organisations today use APIs in some capacity, including APIs powering customer-facing applications; APIs that are consumed or provided in a partner ecosystem; and APIs that are in the cloud or microservice environments. It’s not uncommon for organisations to be unaware of some or all of these APIs. The lack of information that these gaps represent prevents security teams from comprehending the real exposure and risk of an API.
- “APIs are protected by the firewall” – APIs are often taken out from behind the firewall and exposed by developers. Reasons may include testing, enabling third party developer access or partner demonstrations. If security teams aren’t made aware of these exposures, they can present a major threat.
- “Our APIs don’t carry much traffic” – Even low traffic APIs are a valuable target. Many low traffic APIs are a critical part of a business, meaning that they’re likely exposing sensitive data.
- “APIs aren’t important” – APIs provide a pathway to a range of high value services and sensitive data. Gartner predicted that “by 2022, API abuses will move from an infrequent to the most-frequent attack vector, resulting in data breaches for enterprise web applications.” In fact, Gartner re-evaluated this statement in 2021 to say it had already happened.
- “Our APIs aren’t worth attacking” – Even small organisations with little known APIs are at risk, because they typically lack the sophisticated security tactics of larger companies.
- “APIs are hard to attack” – It is often wrongly assumed that APIs benefit from security by obscurity. APIs inherently expose application logic and, when compared to traditional web applications, expose a huge amount of data. Attackers can probe APIs with the same tools as developers, using subtle methods to map the API, understand the logic and look for vulnerabilities.
Dependence on dev teams to address security
Many organisations have adopted DevOps practices, realising efficiencies in the development cycle. It’s natural that they would want to remove similar barriers with security. In the recent Salt Labs State of API Security report, 40% of respondents said developers or DevOps teams hold primary responsibility for securing APIs, but 95% of respondents experienced an API security incident in the past year, highlighting that the burden cannot fall solely on developer shoulders.
Developers make applications work, but attackers make them perform in unintended ways. It’s difficult for developers to shift into an attackers mindset. Despite the methods available to identify potential vulnerabilities, it’s rare that all aspects of code are tested.
Furthermore, as it is so difficult to keep up with today’s ultra-fast code, developers typically only test primary apps or specific areas of functionality and most scanning tools depend on best practices and signatures to identify vulnerabilities. Yet, these approaches are ineffective at identifying unique logic vulnerabilities.
Putting the trust back in software testing in 2022
Reliance on traditional security tools and protections
OWASP’s API Security Top 10 included 70% new threats when compared to the Web Application Top 10. Despite traditional tools being essential, they fail to protect against these new threats.
For example, for customer-facing applications, authentication provides little protection as attackers can easily set up an account and from there probe and view the API. Salt research in the OWASP report showed that 94% of exploits happen against authenticated APIs; authentication alone is not enough.
And while authorisation is essential, it’s tough to get right 100% of the time. The top threat on the OWASP report and the most commonly seen vulnerability is Broken Object Level Authorisation (BOLA), which preys on misconfigured authorisation. The complexity of APIs and API logic means that misconfiguration easily occurs.
Encryption is also needed to protect data both in transit and rest, but it’s easy for attackers to terminate API activity on their own devices using the same tools as developers. These tools enable attackers to view the API and unencrypted data without having to go through “man-in-the-middle” encryption.
Volumetric attacks can be stopped using rate limiting, but it is relatively easy to avoid. Changing phones, IP addresses or launching attacks from ephemeral workloads in the cloud are all effective methods.
Organisations often assume that Web Application Firewalls (WAFs) can be extended to protect APIs. However, their limited architecture prevents them from collecting and analysing the data necessary to prevent attacks targeting API logic. Without this data it is impossible to establish context and identify subtle attack activities.
And finally, even if existing security tools identify and send an alert to a SIEM, incident response teams still need to piece together the activity, eradicate false positives and make sense of what the attacker is trying to do. This is a tough task for even the most advanced incident response team while managing existing alert fatigue.
Next steps
Connecting with development teams using APIs to build their applications can help organisations understand their APIs. They can provide insight into the types of applications built with APIs, how critical they are and the types of data they may expose. Network, infrastructure and operations teams may also provide similar insight.
In addition, augmenting development security efforts with runtime protection to stop attacks will work to ensure that potential vulnerabilities missed in the development stage are not exploitable in production – meaning that development teams don’t need to strive for 100% bug-free code.
Finally, by levelling up traditional tools and methods to use big data to collect API traffic and applying both AI and ML to analyse user activity in tandem helps to gain the context needed to identify and stop attacks. This kind of analysis helps differentiate between normal and malicious attacker activity.
By taking these initial steps, combined with initiating runtime security, organisations can make hardening APIs over time a realistic goal and protect themselves against the next frontier of attacks.
