Application programming interfaces (APIs) are engines driving digital transformation, allowing businesses to connect to customers, partners and suppliers in ways that couldn’t have been imagined a few years ago.
But, like any powerful engine, APIs are dangerous when used without proper safeguards. APIs open businesses to attack. If you think you haven’t been targeted, that means you haven’t detected the attacks.
APIs Are Ubiquitous
APIs are everywhere, enabling essential communications between applications in finances, healthcare, government, elections, the military, our personal lives and more. They connect the intricate moving parts of sophisticated cloud-native applications that run today’s businesses. APIs are included in mobile apps, JavaScript browser interfaces, rich clients and more.
Modern web apps are clusters of interconnected APIs, microservices, frameworks, libraries and serverless functions crossing multiple cloud and on-premises environments.
For example, Netflix runs more than 1,000 microservices managing separate parts of the enterprise, including user management, billing, subscription management, video transcoding, personalized recommendations and more. APIs enable these microservices.
Companies adopting public APIs thrive, with market capitalizations up to 38% higher than their counterparts. Consequently, adoption is growing across the board.
But APIs’ growing ubiquity, and the physical spread of distributed infrastructure where they’re deployed, create API sprawl and present an ever-expanding attack surface for wrongdoers.
The API Threat Landscape
Unsecured APIs have led to significant data breaches. For example:
• The December 2021 Log4j attack was facilitated by API security vulnerabilities, allowing attackers to break into major systems, including Amazon, Apple Baidu, Twitter, and government entities.
• After Clubhouse — an audio-only social chat app — improperly secured its APIs, attackers exposed 1.3 million user records, including IDs, names, Twitter handles and photo URLs.
• An attacker used an authentication-free API to exfiltrate the personal data of about 700 million LinkedIn users in 2021, including phone numbers and email addresses and then offered the data for sale.
And the vulnerabilities continue into today. Some 92% of 397 respondents experienced at least one API-related security incident in the previous year, according to a study by Enterprise Strategy Group and application security vendor Data Theorem.
The actual percentage of organizations experiencing attacks is probably even higher than 92%. My industry experience tells me that the remaining 8% of organizations experienced attacks — attacks that they never detected.
A Fast-Changing Environment
Part of the problem is that APIs change quickly. Rapidly changing APIs make constantly changing attack surfaces that are difficult to protect. Some 75% of respondents to the ESG/Data Theorem study reported they typically change APIs daily or weekly.
New development methodologies such as continuous integration/continuous deployment (CI/CD) lead to greater risk alongside opportunity. The most cited security challenge organizations face with faster CI/CD development cycles is that security lacks visibility and control in development processes, according to 41% of respondents in the ESG/Data Theorem study. The second most cited security challenge is that new builds are deployed to production with misconfigurations, vulnerabilities and other security issues (40%), followed by developers skipping security processes (39%) and software released without security checks and/or testing (38%).
It’s not as if organizations are oblivious to the problem. Some 45% of respondents to the study say they plan to invest in API security tools. Forty-three percent also plan to invest in cloud-native application protection platforms (CNAPPs), while 41% plan to invest in integrated application security and API security tools.
The problem is widespread. According to ESG, the overwhelming majority (80%) of organizations report that all or most of their cloud-native applications use APIs.
APIs need the same AppSec as apps: The security requirements are no different.
And yet, traditional AppSec tools don’t work on APIs. These Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tools were designed for web applications and date to the early 2000s.
What’s Needed to Secure APIs
API security requires five parts:
• API inventory. You can’t secure what you don’t know about. API inventories need to be continuously discovered and tracked throughout the application life cycle.
• Testing. You must deploy testing to find vulnerabilities in APIs, microservices and functions.
• Supply chain. You need to secure all your software components, including third-party libraries, frameworks and services.
• Identifying probes and attacks. To protect your infrastructure, you need to know what’s coming at you, identify known and unknown vulnerabilities, and prevent exploitation.
• Access control. You need to implement strong authentication and authorization on functions at the API level as well as the data level.
Instead of relying on traditional AppSec tools, developers should implement software instrumentation throughout the application life cycle. This instrumentation analyzes events in all components, including libraries, the API server and platforms, as well as the interactions between those pieces. Instrumentation adds monitoring code to the application at runtime, exactly the way application performance management (APM) tools do, to identify vulnerabilities and protect against sophisticated exploits in real-time.
Organizations should also consider threat modeling every new API. One method to consider is an approach called Lite Threat Modeling (LTM).
Keeping It Lite
LTM involves stakeholders in a streamlined approach to identify, assess and mitigate potential security threats and vulnerabilities. Using LTM, security professionals ask who would want to attack which system components, identifying the worst possible outcome of a break-in and how that outcome would affect the company and customers. As the name suggests, it’s a simplified version of traditional threat modeling, which typically involves a more comprehensive and detailed analysis of security risks.
LTMs are best performed whenever a new feature is released, security control is changed, or changes are made to existing system architecture or infrastructure. Ideally, LTMs are performed after the design phase and before implementation because it’s much easier to fix a vulnerability before it’s released into production.
In Conclusion
In order to secure APIs, you have to treat them like applications, given that they entail the same security risks. That means taking the time to threat model them as you would any security risk, as well as establishing clear, consistent processes and standards for dealing with both applications and APIs throughout the organization.
