Shift-left API security: Protect your APIs before releasing to the cloud

APIs are essential to software development and innovation but they are – by their very nature – a critical component in the application attack surface. An entire industry has popped up focused solely on API Security and there is even an OWASP API Security Project, with its own list of Top 10 vulnerabilities and risks.

But despite the Shift Left movement in Application Security, API discovery, governance, testing, and observability have remained firmly in the realm of production systems. It’s time to uncover, prioritize, and remediate API security risks at the commit or Pull Request before they reach production (i.e. Shift Left approach).

This means involving not only Cloud Security experts but AppSec and Developers as well so you can protect your APIs from design to development before releasing to the cloud.

API Security Breaches

Existing API Security approaches have rapidly transformed from “good enough” to “unacceptable” as breaches continue to pile up:

• Equifax (2017) – Personal data of 148 million consumers was exposed in one of the most highly-publicized and damaging cybersecurity breaches of all time. The issue came from unpatched instances of Apache Struts and not properly enforcing formats for incoming API calls.
• Clubhouse (2020) – A SQL database containing 1.3 million user records was scraped using a public API and was put up for sale on the dark web. While Clubhouse denies that this constituted a “breach”, which further demonstrates the nuances involved in API security.
• Experian (2021) – A security researcher discovered that it was possible to look up the credit score of tens of millions of Americans by using publicly-available information, such as name and address.

The Problem with Traditional API Security

Cloud Security professionals cannot resolve the problem alone. In “API Security: What You Need to Do to Protect Your APIs”, Gartner states:

“Despite growing awareness of API security, breaches continue to occur. API management and web application firewall vendors, as well as new startups, are addressing the problem. But application leaders independently must design and execute an effective API security strategy to protect their APIs.”*

Application Security engineers must understand their attack surface:

• How many APIs do they have across their code repositories
• Which APIs are internet-facing, sensitive, and missing authorization
• How many APIs expose sensitive data (e.g. PII, PHI, PCI) and are internet-facing
• Which APIs are behind an API gateway without input validation
• Which APIs read or write from a cloud storage bucket

API Gateways provide capabilities such as authentication, authorization, and input validation controls when publishing APIs. But existing tools fall short in the area of API discovery, classification, and observability early in the SDLC with the ability to block risks at the Pull Request before deploying to the cloud.

API Security Starts at the Design

Security design patterns that are often neglected in APIs can include:

• Keys that are included in the URI
• Authorization is not required by default
• Enforcement of API Security by a gateway layer (e.g., stack trace blocking, authorization, federated authentication, input validation)
• Strict versioning and caching controls

Note: the challenge in capturing these risks at the design stage is to automatically identify and prioritize user stories (i.e. feature requests) that require the development of new APIs or modification of existing ones. Read this blog on how to implement this approach – Security at the Design.

Protect your APIs Requires Context

In order to address the limitations of traditional API Gateways and other runtime security tools, Application Security professionals can leverage context from both Infrastructure-as-Code (IaC) and application code to make more informed – and earlier – decisions about API risks.

Understanding the impact of changes to an application architecture is essential to Application Security professionals. In order to understand the impact of a change, a security professional must be able to understand the full attack surface across the application architecture, with context from cloud infrastructure and API security controls to the source code itself. API Security cannot remain a standalone function. This is just one component in the architecture of the application. According to Gartner:

Application Security professionals need to be able to tie all Infra-as-Code and API changes to the correct repository, commit, Pull Request, Jira ticket, and developer to understand all the context and see a full history of all changes, who requested them and why. 

In addition, a change doesn’t have to be in the API code to affect the security of an API! If application code is modified to store new types of sensitive data (e.g. PII, PHI or PCI), the risk of individual APIs may increase significantly. True end-to-end API Security requires a contextual static code, data flow, and text analysis with a risk-based view that extends across the entire software supply chain.

Connect Apiiro to your source control manager and API gateways in minutes via read-only API to discover all your APIs in the source code and remediate risks before releasing to the cloud, create a user and start a free trial!

*Gartner, Inc. “API Security: What You Need to Do to Protect Your APIs.” Mark O’Neill, Dionisio Zumerle, and Jeremy D’Hoinne. 1 March 2021.