3 Reasons You Might Be Failing at API Security
APIs have been around for the better part of 20 years and have evolved significantly since the early days when a limited set of companies used APIs to address a limited set of needs. In recent years, use has exploded, with APIs becoming increasingly prevalent in the application environments of businesses of all sizes to address a seemingly endless set of use cases.
Today’s APIs are found across application environments to enable rapid development, fuel digital transformation initiatives, and connect customers and partners with services. APIs today also expose more sensitive data than ever before, making them a valuable target for attacks.
As APIs have increased in prominence and as a target for attacks, organizations have become more aware of the need for proper security, but as with adopting any new technology, misconceptions persist about how to get it right. No matter where you are on your API and API security journey, check out these three reasons you might be failing at API security.
Lack of awareness
Many organizations have not come to terms with the risk that APIs present because they lack the right level awareness and visibility into their attack surface. Traditionally, visibility of APIs depends on manual efforts that fall short of providing a complete picture, and constant change makes maintaining visibility even more challenging. Organizations often fall into one or more of the following categories when it comes to acknowledging the risk APIs present in their environment:
We don’t have any APIs
Some organizations think they don’t have any APIs at all. The reality is that APIs are everywhere, and most organizations today are using APIs in some way in their environment. Usage includes APIs that power customer-facing applications, APIs that you consume or provide in your partner ecosystem, and APIs that are in your cloud and microservices environments.
We don’t have many APIs
Even customers who know that they have APIs aren’t always aware of all the APIs they have. Unknown shadow APIs and forgotten zombie APIs present a significant, unrealized risk.
Even thinking you have a handle on all of your known and unknown APIs is not enough. Salt research has found gaps of up to 40% when comparing customer-provided documentation with APIs running in production. These gaps include incomplete and inaccurate documentation that lacks details such as missing endpoints, unknown functionality, and exposed sensitive data. Without this level of accurate detail, security teams cannot understand the true exposure and risk that an API presents.
All our APIs are safe behind the firewall
Many organizations think that all their APIs are behind the firewall, protected in their development environments. The reality is that APIs are more exposed than you think. Developers might expose APIs externally for various reasons, including testing, enabling 3rd party developer access, and demos for partners. All these scenarios present a significant risk if exposed without the knowledge of security teams.
There isn’t much traffic going through our APIs
It’s not about the volume of traffic but rather the value of the service and data. An API may have low traffic volume but is still a critical part of your business to drive revenue or enable your partners. These types of APIs are also likely exposing sensitive data, increasing their value as a target. Attackers don’t care how much traffic traverses your API; they care about the value of the target.
Our APIs don’t expose anything important
The reality is that by nature, APIs are the pathway to a wide range of high value services and sensitive data. Attackers know this often better than those who build the APIs, and it’s one of the many reasons Gartner says, “by 2022, API abuses will move from an infrequent to the most-frequent attack vector, resulting in data breaches for enterprise web applications.” Understanding the sensitive data that your APIs expose can also be an essential component of understanding risk and meeting compliance requirements.”
No one would care about our APIs
Maybe you’re a small company and think you wouldn’t be a target for an attack. Maybe your APIs power services that are not well known or widely used. But just because your company and APIs aren’t considered high profile doesn’t mean they’re not targets. Some attackers may prefer smaller organizations thinking those targets would be easier than higher-profile companies with more sophisticated security practices.
It’s hard to attack APIs
Many think that APIs are hidden behind the scenes and therefore benefit from some level of security by obscurity. The reality is APIs, by nature, expose application logic and much more data when compared to traditional web applications. Attackers can easily probe APIs using the same tools that your developers do, allowing them to use subtle methods to map the API, understand the logic, and look for vulnerabilities.
Learn why apps are built on APIs, the security risk APIs present, and best practices for securing APIs.
Download NowOver reliance on dev teams to address security
The desire to shift left has been a big trend in recent years. Organizations that have adopted DevOps practices have realized efficiencies in the development cycle and want to remove similar barriers with security.
This trend has carried into API security, where the assumption has been that development must address API security or the application will never be truly secure. We saw proof of this perspective in the State of API Security Report 2021, where 36% of respondents say developers or DevOps teams hold primary responsibility for securing APIs. Efforts pre-deployment include everything from secure coding best practices, code scanning, and manual testing. The State of API Security report also showed that 91% of respondents experienced an API security incident in 2020, proving that these DevOps security practices, while important, are not enough.
Developers continue to get better about incorporating best practices and developing secure code; however, developers do not think like attackers. Developers focus on functionality and ways to make applications work. On the other hand, attackers look to make applications perform in ways that were unintended. A developer trying to deliver code quickly can't efficiently shift into an attacker's mindset to try to eliminate all of the potential vulnerabilities.
Development teams also know that there is no such thing as 100% bug-free code. That's why they use code scanners and leverage penetration testing to complement efforts and identify potential vulnerabilities as code makes its way to production. These tools and practices have their limitations, and due to cost and complexity, all aspects of code rarely are tested.
Time is another major factor. With code pushed faster and faster, it's challenging for pre-production security efforts to keep up, resulting in cutting corners to meet deadlines. Often, the priority is to test only the primary apps or specific areas of functionality.
Another factor is that most API vulnerabilities are a function of each API's unique logic. Many scanning tools depend on best practices and signatures to identify vulnerabilities, and neither of these approaches will identify unique logic vulnerabilities. Even with customization and manual efforts like penetration testing, it's difficult, if not impossible, to identify logic vulnerabilities, many of which are found only at runtime.
Overconfidence in traditional security tools and protections
APIs and API vulnerabilities are anything but traditional; yet, many organizations still rely on traditional tools such as API gateways and Web Application Firewalls (WAFs) and traditional protection methods for security. At the end of 2019, OWASP released the API Security Top 10, a list that includes 70% new threats compared with the well-known Web Application Top 10, highlighting the difference of APIs compared to traditional web applications.
Many API gateways employ traditional protections such as authentication, authorization, encryption, and rate-limiting. These are essential parts of protecting any application, but not nearly enough to protect against the threats in the new API Security Top 10. The majority of threats to APIs, especially the more sophisticated ones, occur beyond these protections.
Authentication provides little protection for customer-facing applications. For many of these applications setting up an account takes a matter of minutes, and an attacker then has access to view and probe the API. Authentication alone does protect more restricted applications, either. Poor password practices, leaked credentials, and phishing all impact the risk of depending solely on authentication. Salt research in the State of API Security Report found that 96% of exploits happen against authenticated APIs, highlighting that authentication alone is not enough.
Authorization is also essential but difficult, if not impossible, to get right 100% of the time. The top threat on the OWASP API security Top 10 and the most commonly seen vulnerability is Broken Object Level Authorization (BOLA) which takes advantage of misconfigured authorization. The complexity of APIs and API logic compounded by rapid change makes authorization challenging to get right and difficult to maintain.
Encryption is needed to protect data in transit and at rest. Still, with APIs, attackers can easily terminate API activity on their own devices using the same tools your developers do. With these tools, attackers can view the API and unencrypted data without jumping through hoops to “man-in-the-middle” encryption.
Rate limiting can help stop volumetric attacks such as DDoS, credential stuffing, and bot activity. However, attackers avoid rate limits in several ways, like using burner phones, changing IP addresses, and launching attacks from ephemeral workloads in the cloud. Attackers know that by using these methods, they can either stay under limits or keep ahead of the rate limit policies that require creation and updating. Rate limiting also does nothing to protect against the majority of the OWASP API Security Top 10 threats, characterized as low and slow attacks where attackers probe and manipulate APIs with subtle methods that do not trigger rate limits.
Some organizations think APIs are just another application, so tools like WAFs can be extended to provide enough protection. To confuse matters even further, many WAF vendors include mention of APIs in their marketing literature. WAFs can protect APIs from traditional threats, but completely miss attacks that target the logic of APIs. These low and slow attacks take place across many transactions over hours or days, and as mentioned in a previous post, proxy-based tools such as WAFs have limiting architecture and lack the ability to collect and analyze the large amounts of data required to establish context and identify these subtle attacker activities.
SIEMs also fall into the category of traditional tools playing an essential role in any security environment but falling short in identifying and preventing API attacks. Assuming that existing security tools can identify and send an alert to a SIEM, incident response teams will still have to piece together the activity, weed out false positives, and make sense of what the attacker is trying to do. Making sense of what the attacker is trying to do requires deep knowledge of the application, including the API logic, and what normal activity looks like, something even the most advanced incident response team will struggle with while managing their existing alert fatigue.
What you need to do next
Understand the role APIs play in your environment
If you’re unaware of the APIs in your environment, the first step is to connect with development teams who are likely using APIs to build their applications. Development teams can also provide insights into the types of applications built with APIs, how critical those APIs are to the business, and the types of data those APIs might expose. Other good sources of insight include network, infrastructure, and operations teams who can provide details on API usage across your environment.
These discussions will provide a good starting point to understand where and the types of APIs that exist. Employing an automated tool like Salt will provide a complete picture by allowing you to automatically and continuously discover APIs, including those that are known and unknown. Salt also helps create an API catalog, identify sensitive data exposure, and maintain a realistic view of your APIs even as they change.
Augment development security efforts with runtime protection to stop attacks
It’s essential to think of API security as activity across the full lifecycle of APIs. Adding runtime protection like Salt helps to ensure that any potential vulnerabilities missed in development are not exploitable in production. This protection also allows development teams to move at the speed required to meet deadlines while not being slowed by starving for 100% vulnerability-free code.
Salt also enables a feedback loop that provides runtime insights to share with development teams to help them identify, prioritize, and eliminate vulnerabilities. The discovery capabilities of Salt provides a complete picture of APIs, including granular details to enrich documentation. Salt also provides insights into potential gaps that help development teams eliminate vulnerabilities earlier in the development cycle. Salt also goes beyond stopping attacks and is unique in using attackers like penetration testers to aid remediation activity with valuable insights into how attackers try to manipulate potential gaps.
Go beyond traditional tools and methods
Authentication, authorization, encryption, and rate-limiting all have their place in securing APIs, but they’re not enough. Tools like WAFs are architecturally limited and not suited to identify and stop the majority of API attacks.
Salt uses big data to collect API traffic and applies AI and ML to analyze the activity of millions of users in parallel to gain the context needed to identify and stop attacks. Through analysis, Salt creates a baseline of normal behavior for every API and identifies anomalies. With the context it creates, Salt differentiates between API changes or simple mistakes vs. malicious attacker activity. Correlation of activity allows Salt to pinpoint attackers and stop them early in their reconnaissance process to prevent successful attacks.
The Salt alerts contain the context incident response teams need to understand and respond to events quickly. Salt alerts contain the full timeline of attacker activity with details on what the attacker did and how the application responded so teams do not need to correlate information manually.
Want to learn how Salt can help you win the API security battle? Request a personalized demo to see how Salt helps you discover all your APIs, prevent attacks, and improve your API security posture.
