One game that many children learn is checkers. Players feel special when they get fancy checkers made of specialty wood or marble, but it’s still just checkers. For checkers players to take on a game change that significantly challenges their thinking, a typical next step is chess.
While still involving strategy against an opponent using the same style of board, this change takes a transformed way of thinking (a transformation that is enough of a challenge to decide one’s future regarding strategic thinking).
So it is with API security – there are new threats that require transforming the way one thinks about securing the endpoints.
Practice Transformations Affect Security Programs
Some API-related modern practices that differ from the past are the increased usage of APIs, the rise of micro services architecture, the adoption of cloud computing and DevOps practices, and increased regulation.
Increased API use
As more applications rely on APIs to communicate and share data, the risks associated with API security have increased. This has led to a greater emphasis on securing APIs against modern threats, such as API abuse and bot attacks.
The rise of microservices architecture – in which applications are composed of small, independently deployable services – has led to an increase in the number of APIs that an organization must secure. This requires a different approach to security that needs to address the unique challenges of securing large numbers of APIs.
(For an interesting and alternate view on the trend toward microservices, see this article by David Heinemeier Hansson)
Many organizations are now using cloud-based services to host their APIs, introducing new security challenges such as shared responsibility models and securing access to cloud-based resources.
The adoption of DevOps practices has led to a faster pace of development and deployment, which can make it difficult to ensure that APIs are secure. This requires a shift towards security practices that are integrated into the development and deployment process.
Increased regulation and Compliance Requirements
With the rise of data privacy regulations such as GDPR and CCPA, organizations must ensure that their APIs are compliant with these regulations. This requires a greater emphasis on data security and privacy protection. Failing to comply with these regulations can result in significant fines and reputational damage. One can track US data privacy and international laws online.
Transformations in Risk
In addition to transformed practices and accelerate changes in the regulatory landscape, there are also changes in attack methods and attack surfaces.
Authentication and Authorization
A primary concern with APIs is ensuring that only authorized users or applications can access them. This requires proper authentication and authorization mechanisms to prevent unauthorized access or misuse of the API.
APIs are often targeted by attackers attempting to exploit vulnerabilities in the API to steal sensitive data or perform other malicious activities. Common types of API abuse include credential stuffing, denial of service attacks, and data scraping.
APIs often handle sensitive data, such as personally identifiable information (PII) or financial information. Ensuring the security of this data is crucial to protecting both the users and the organization. Being the gateway to enormous amounts of sensitive data makes APIs a leading target.
Bots are increasing in sophistication, being used to launch automated attacks on APIs. The intent is to achieve malicious goals such as account takeovers and data theft.
Many APIs rely on third-party services or libraries, which automatically introduce additional security risks (while seemingly benign, even an outage at a third-party affects the Availability aspect of security). Organizations must ensure that third-party dependencies meet the same security standards as their own APIs.
Low and Slow Attacks Target APIs
A more specific example of an attack that is often aimed at APIs is the low-and-slow attack. APIs are meant to be used heavily, like a revolving door in a large hotel. With that design, it’s difficult to tell if someone entering by the public-facing portal is a threat actor or not just by how they look – they’re not causing trouble, lots of other people are entering, and they’re allowed entry even if they’re not really doing business. (Fortunately, unlike hotels and malls and such, we’re not dealing physically with people, and much of API abuse is automated bot activity, so there’s more analytic information to draw from).
The low-and-slow attack involves normal and trickling activity – nothing alarming, no DDoS attempt, no overtly suspicious requests. But attackers take advantage of API design to gather information without setting off the typical alarms that would alert security personnel to potentially criminal activity.
Combined with the statistic that 78% of attacks come from threat actors who have compromised legitimate accounts ,this attack style has proven effective.
Wanted: The Right Tools
With all the new additions to the threat landscape, here are a few tools to consider (in addition to traditional protections such as logging and monitoring, access control, and detecting cross-site scripting – the traditional risks are evergreen) when looking for solutions.
- Rate limiting: This technique limits the number of requests that can be made to an API over a given time period. This can help prevent DDoS attacks and other high-volume attacks that rely on flooding an API with requests.
- Captchas and challenges: Captchas and challenges can be used to verify that a user is human and not a bot. These mechanisms may include image recognition challenges, puzzles, or other techniques that require human intelligence to solve.
- Behavior-based analysis: This analysis can be used to identify and block bots based on their behavior patterns. For example, a high volume of requests from a single IP address in a short amount of time may indicate that a bot is being used to launch an attack.
By keeping up with the ever-changing trends in technological threats, while not discarding relevant traditional threats, one can transform the API security program as needed. It takes vigilance, but it’s feasible. Take the next step.