Scissors are great, but not for mowing the lawn. Knives are great for preparing dinner, but not for milling lumber. Each task requires the right tool. And just because a tool isn't fit for purpose doesn't mean it's not a good tool - it might just not be the right one for that job.
The same idea applies to virtual tools, such as WAFs and bot detection. In and of themselves, there's nothing right or wrong about them; they just need to be well-suited to the intended purpose. Too often, as technology changes, older tools are kept around, and frequently for various rational reasons - financial investment in the tool, organizational training on the software, even numerous corporate systems embedded with the product.
There can be great discomfort when change happens, but in technology, change has to happen and adaptations have to be made. One change that has affected businesses for the better is Application Programming Interfaces (APIs). APIs improve business capabilities, and therefore revenue. But that change also requires other changes, which can range from uncomfortable to disruptive.
APIs can connect virtually any processes. A few common examples are:
● Sharing flight information between airlines and travel sites
● Using Google Maps in rideshare apps
● Integrating chatbots with messaging services
To improve transaction speed and improve personal lives, from pretty much anywhere:
● PayPal allows people to pay
● Okta provides secure authentication
● Google Maps gives directions
● Social media platforms can integrate with one's login credentials, and
● A quick internet search provides a hometown's weather forecast.
APIs are almost literally everywhere. With internet-connected technology, this rapid expansion of capabilities comes with the cost of having to secure those expansive borders.
Highlighting the need for proper security, here are a couple of examples of how API vulnerabilities have been exploited to create trouble for millions of people.
In 2021, data sets of Twitter user accounts were created when threat actors exploited a Twitter API vulnerability. Twitter fixed the vulnerability in January 2022, but in July 2022 it found the phone numbers and email addresses of those accounts up for sale on a forum (fixing a vulnerability never means that stolen data is retrieved).
See here for technical specifics on the exploit, provided by a security researcher.
In January 2023, T-Mobile announced that it had been the victim of a data breach that exposed the personal information of 37 million customers. The breach was carried out in November 2022 through an API flaw, which allowed criminals to access customer data such as name, email, date of birth, and phone number.
There’s no doubt that APIs are different in their technological structure. So vastly different, especially from typical web applications, that they can’t be protected with traditional web app (or even traditional API) security tools such as API gateways, log file analysis, and WAF alerts.
This isn’t just technological philosophical pontification. In a recent API security report, 77% of API defenders surveyed said “their existing tools aren’t very effective in preventing API attacks.”
What makes these traditional tools fail when attempting to protect APIs?
Traditional security tools are designed primarily to protect web applications and network infrastructure, but they may lack the specific features needed to address API-specific vulnerabilities, such as broken object level authorization (BOLA), inadequate input validation, or insufficient rate limiting.
Modern applications often rely on numerous APIs which may be sourced from different providers. The complexity of these landscapes make it challenging for traditional security tools to monitor API traffic and detect suspicious activity.
Traditional security tools may not provide the level of visibility required to detect API-specific attacks (e.g., credential stuffing, brute force) which can occur across multiple APIs and require granular API-level visibility.
APIs require more advanced authentication and authorization (e.g., token-based) mechanisms than traditional security tools provide.
APIs operate in highly dynamic environments, with new APIs being deployed and existing APIs updated or replaced frequently. Traditional security tools may not be able to keep up with the rapid changes, resulting in control gaps that can be exploited.
There’s more to API security than just keeping attackers from stealing data. It’s just as important to ensure the API is available as promised, be able to monitor traffic (low-and-slow is a common attack that isn’t easily detected), and provide encryption that protects data in case it is stolen (threat actors can’t benefit from what they can’t use).
A good API-specific toolset should include the following features:
Good tools should include features that specifically address API security issues, such as BOLA, input validation, low-and-slow attacks, rate limiting, and traffic monitoring.
The toolset should provide granular visibility into API traffic, including detailed information about API requests and responses, as well as the ability to track API calls across multiple systems.
Tools need to provide advanced authentication and authorization mechanisms that are specific to APIs, such as token-based authentication and authorization frameworks. Strongly consider support for OAuth, OpenID Connect, and other industry-standard protocols.
Advanced threat detection capabilities that are specific to API environments are a must, such as detecting credential stuffing and brute force attacks.
API toolsets should be easy to integrate with existing API infrastructure, including API gateways, API management tools, and other security systems.
The toolset should include automated testing features that enable developers to test APIs for security vulnerabilities as part of their development workflows.
Regulatory compliance is a cornerstone of transmitting or storing customer information. The toolset should support compliance management frameworks, such as PCI DSS, HIPAA, and GDPR, to help organizations ensure that their APIs meet regulatory requirements.
Personnel, trusted advisors, and consultants properly trained in securing businesses are your best resources in protecting APIs. Tools are only as good as their handlers. It can be discomfiting but trust your security program to security-minded professionals.
A few other aspects of a full API security program – each requiring human intervention - include implementing API security best practices (start with OWASP API Top Ten), conducting regular security assessments and testing (beyond automated), and ensuring API documentation is up-to-date and accurate.
Even though it can be a stretch, there’s no reason to think that API security is beyond your reach.