March 24 2022 | 3 min read
Technical | March 24 2022 | 3 min read
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:
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:
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:
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.