Application programming interfaces are modern application architecture solutions that enable digital business by improving connectivity and enabling composable architectures. They are used to support modern user experiences across web, mobile and other channels. They also support internal processes, customer and partner integration and automation.

Growth of API deployments has exploded over the past decade, but with this popularity has come the attention of malicious actors. Many API security incidents have already occurred, particularly in the form of data leaks. These incidents have raised awareness of API vulnerabilities, but attacks and breaches continue to arise due to the massive amount of web traffic that is comprised of API interactions.

Many organizations protect API traffic the same way they protect their legacy applications. However, generic application security controls are not sufficient to secure API transactions. Security and risk management leaders, in collaboration with application technical professionals, must establish and mature their API security programs to address this growing threat landscape.

Visibility: What APIs exist within your landscape?

Many API breaches have one thing in common: the breached organization didn’t know about their unsecured API until it was too late. The first step in API security is to discover the APIs the organization delivers or consumes from third parties.

Mobile and web applications are a good place to start. Another common source of APIs is application integration, which involves APIs used by integration products to provide access to applications or data. Some organizations may also have an open API program including a developer portal, and these public APIs must be secured. Finally, consider any third-party APIs the organization uses.

After discovering the organization’s APIs, the next step is to categorize them based on exposure, business context and technology. Then, identify the APIs’ potential vulnerabilities. The most common API vulnerability paths include:

• Unsecured API keys in repositories and storage: API keys or other keys, such as SSH keys or SSL/TLS private keys, may be discovered in cloud-based storage or in code repositories which are left open to the public.
• Hardcoded API keys in applications: API keys or other credentials may be hardcoded in web and mobile applications and subject to decompiling attacks, on internet of things devices, or in mobile apps.
• API logic flaws: APIs may have bugs or other logic flaws which can be exploited.
• Sniffed API calls: API traffic may be sniffed through a man-in-the-middle approach, uncovering API keys or unsecured APIs.

Access control: Who is accessing your APIs and what access do they have?

Access control is a significant part of API security. It encompasses authentication, the process through which a subject’s identity is verified, and authorization, the process that determines if a subject has access to a specific resource.

Vulnerabilities in access control functions are typically the most common attack points against APIs, leading to data exposure, loss and manipulation. Web applications have historically used basic authentication (username and password) to allow user access. When organizations start deploying APIs, this mechanism is usually inherited.

Mature organizations use modern API access control mechanisms. A modern API access control strategy is based on an assessment of an organization’s use cases across four key dimensions:

• Identity functions: Identity functions for API use cases are authentication, authorization and encryption. The identity fabric, meaning the tools that need to be orchestrated together to solve identity needs, varies depending on what identity functions are in scope for the organization.
• Applications: Mobile apps, internal or external services, web applications and devices are all examples of applications that access protected APIs. The apps are typically operated by users or machine identities such as service accounts. Different apps have different capabilities for how they can authenticate themselves and the human users piloting them.
• Mediators: APIs are protected by mediators such as enterprise or internal API gateways, as well as more nimble mediators such as sidecars deployed close to the APIs. Assessing the mediators’ identity capabilities ensures that the API access strategy includes the right integrations and enforcement in the mediators. It also enables organizations to assess the access management tools support for the mediators used.
• Developer enablement: Developer enablement ensures that developers can publish and control their own APIs and control what attributes they need in their APIs. At the same time, the control must be based on a delegated model in which a central team controls the overarching policies. Understanding the developer enablement dimension ensures that the strategy includes the right tooling support, such as developer self-service interfaces.

To ensure that proper risk assessments and classifications are made, use these dimensions to define the organization’s API access control requirements.

Threat protection: How can attackers exploit your APIs?

API security programs must protect against three common attack patterns: denial of service, abuse of functionality and vulnerability exploits. API threat protection consists of runtime or perimeter technologies that identify and protect against attacks that fall into these three categories.

Typical technologies for threat protection include:

• DDoS protection: Solutions that have the capacity to handle volumetric attacks include content delivery networks or CDNs, cloud-based and appliance web application firewalls or WAFs, and cloud scrubbing center or CSC platforms. For application-layer DoS attacks, hardware or cloud-based WAFs with DoS capabilities can be appropriate. Once the attack ramps up to become volumetric and begins to overwhelm network links, a CDN or external CSC is required.
• WAF: A solution that provides limited protection for APIs by filtering and monitoring HTTP traffic looking to block common exploit attacks. Some WAFs also offer bot mitigation and application or Layer 7 DDoS protection.
• Bot mitigation: A solution that provides advanced protection across many types of scripted attacks. These solutions are more capable in this area than the average WAF, which makes them a possible first choice or complement for abuse prevention.
• Specialized API protection: Solutions that provide protection against API exploits and abuse through a combination of content inspection of parameters and payloads, traffic management and traffic analysis for anomaly detection.

These technologies together make up a web application and API protection or WAAP solution. Along with WAAP capabilities, organizations often add API gateways and management systems to their infrastructure.

As the API threat landscape grows, application security leaders must establish and mature their API security programs to address this growing threat landscape. This approach can help organizations establish a comprehensive plan for API visibility, set mechanisms to check the compliance of APIs to the organization’s authentication and encryption standards, and deploy specialized threat protection for critical external-facing APIs.

William Dupre is a senior director analyst at Gartner Inc., advising clients on software and application security practices, DevSecOps, mobile application security and API security. Gartner analysts will provide additional insights on the latest application security strategies at Gartner Application Innovation & Business Solutions Summit taking place May 22-24 in Las Vegas, and at the Gartner Security and Risk Management Summit taking place June 5-7 in National Harbor, Maryland.

Image: Jan Alexander/Pixabay