Today, Checkmarx announces the launch of Checkmarx API Security. For us, this is one of the most exciting product launches of the year, because it addresses such a real and large pain point for our customers – the problem of shadow and zombie APIs. It’s particularly fascinating because it highlights that the problem isn’t always one of technology. In this case, the problem is more of an organizational one – different developer teams in a larger organization creating APIs faster than security can keep up with.
Because the problem is organizational, the solution to the problem can’t be a reactive one. It must be proactive. With API Security, Checkmarx is taking a fundamentally different approach, a true shift-left approach to help proactively address the problem of shadow and zombie APIs.
What is an API?
API stands for Application Programming Interface. It’s a set of definitions and protocols (e.g., REST, SOAP) that define how you can communicate with a software component or service. This may sound abstract, but it’s really not. It’s basically just a mechanism to perform a transaction – you request information by asking the right question, and the application provides it in response.
Think of the real-world analogy of a bank transaction. I can go into a bank and request money by filling out a withdrawal slip and handing it to the teller, along with my ID to prove that I’m the account owner. Here, I’m the client. The teller is the API. My name, account number, and ID are the parameters that I pass to the API. The money being withdrawn is the data. And the deposit slip is the API documentation.
Why are APIs important?
APIs are a key architectural component that enables broader architectural changes like cloud migration, shift to microservices-based architectures, and agile development. APIs allow for an application to be broken down into multiple smaller components (e.g., microservices), by establishing a clearly defined protocol for those different components and services to communicate and share data with each other.
Figure 1: an example ecommerce web application comprised of microservices deployed across multiple cloud providers and SaaS services.
For example, organizations building a cloud-native application typically split the application into many smaller microservices that must communicate with each other to comprise the whole. This allows them to scale different microservices with different scaling requirements independently of each other to better take advantage of the cloud. In addition, different developer teams can build, deploy, and update different microservices independently of and in parallel with each other, allowing them to move and release software faster.
What is API security?
When you visit a website in your browser, that browser may be showing content and data retrieved from different backend application services using APIs. Likewise, when you open a mobile app on your phone, that mobile app also typically retrieves data from backend services using APIs. These browsers and apps are communicating with APIs over the open Internet, which means… that those APIs must be publicly available on the Internet.
When you combine that with the fact that the primary purpose of APIs is to share data – and share data more efficiently – APIs are ripe for abuse. What type of abuse? The OWASP Foundation maintains a list of the API Security Top 10 risks to help security professionals understand the different types when building APIs. Erez Yalon does an excellent job breaking these down here. Regardless, with the prevalence of publicly exposed APIs, it is no wonder that the number of API-based attacks are increasing. In this recent example, Checkmarx researchers discovered a vulnerability in the Amazon Photos Android app that would have allowed an attacker to steal a user’s Amazon access token and use it to authenticate with and access other API-based Amazon services to steal PII (Personally Identifiable Information) or other information.
API security refers to the task of securing APIs from attack, either by identifying and blocking live attacks, or fixing vulnerabilities in APIs before they go live and can be attacked.
Why is this a problem now?
API security has always been a problem. However, recent years have seen rapid growth in the use of APIs when building modern applications. For example, Postman reported a 56% growth YoY in the number of API requests in its 2021 State of the API Report. And 49% of developers surveyed said that more than half of their organization’s development effort was dedicated to APIs – an increase of over 40% from the previous year.
This growth has dramatically increased both the attractiveness of APIs as a target of attack, as well as the severity of the challenge facing application security teams. The size of the problem keeps getting bigger every year. Security teams are realizing that they cannot kick the can down the road forever, or continue reactively plugging holes, and need a permanent solution now.
OK. So why hasn’t this problem already been solved?
First, a disclaimer – there are existing API security solutions today. In the AST (Application Security Testing) market, vendors including Checkmarx have always helped secure applications against OWASP API Top 10 risks, simply by scanning API code for vulnerabilities. And runtime solutions like web application firewalls (WAFs) and API gateways have provided varying levels of API protection capabilities for years. However, these solutions have not solved the problem, because the problem is not really that we cannot protect an API against attack. The problem is that security teams do not know what APIs they have.
Figure 2: existing API security approaches are limited by what they can see.
Consider a WAF (Web Application Firewall). Security teams can configure a WAF to protect an API. This requires registering the API with the WAF appliance, so it knows where the API is (the URL), what it looks like (parameters), and what good traffic looks like (a positive security model). Because an organization can have 100’s or 1000’s of APIs that frequently change, manually registering every API is not practical. The better way is to import API documentation or design files that describe the API in a standard format, such as Swagger, RAML, or Open API. However, there are two problems here:
- The first is that many APIs are not documented. Sometimes, developers do not document an API. Other times, nobody shared that documentation with security. Regardless, if security teams do not have the documentation, then they do not know about the API, and they cannot configure the WAF to protect it.
- The second problem is that Swagger and RAML files are typically created in the design phase before coding begins. APIs then must be coded, and developers may inadvertently stray from the design when coding the API. Bugs happen. Many API vulnerabilities result from differences between an API’s documentation and what was actually written in code, and these cannot be found by looking at the documentation.
More recently, API threat protection solutions have entered the market to discover undocumented APIs. These work by integrating with WAFs, API gateways, and other network devices such as load balancers. They analyze the traffic going through them to discover some of your shadow APIs that the traffic is going to, but cannot solve the problem, because:
- They are limited to what they can see. They can only see the traffic going through the devices they integrate with. If there are APIs that are not behind these devices, then they cannot see them. Think about your application infrastructure. How many services do you have, and where are they deployed? How many WAFs, API gateways, and load balancers are in your environment that would need to be integrated with? And how often does your infrastructure change, affecting where services are deployed and where traffic flows?
- The other problem is that you are still trying to fix the problem in production. While these solutions may claim to be “shift left,” analyzing live traffic to APIs already in production is not. First, APIs may already be under attack. But more importantly, discovering APIs in production means that security teams must go back and find the developers who coded them. And by the time they do, those developers have already moved on to other projects and have to context-switch back, lowering their productivity and slowing down those other projects.
Figure 3: Checkmarx takes a fundamentally approach to discovering and inventorying APIs
Great, how do you do it differently?
Checkmarx API Security takes a true shift-left approach to help customers address the problem of shadow and zombie APIs. This is a fundamentally different approach to the problem than other solutions described above, which follows several key tenets:
Figure 4: Four key pillars to the Checkmarx solution
- Discover and inventory APIs in source code:
All the solutions described above are dependent on security teams knowing all the chokepoints in the application infrastructure through which API traffic flows. The problem is that most security teams do not know all the chokepoints for all their applications, and the chokepoints they do know continuously change as application services are deployed, moved, or changed.
Instead, Checkmarx scans application source code as it is checked in to discover and inventory all the APIs that are written and exist in code. This happens while scanning source code for vulnerabilities, which we then connect to the specific APIs in which those vulnerabilities are found to provide an API-centric view on risk. Imagine being able to look at all your APIs, pick your most critical ones (for example, your login APIs), and prioritize vulnerabilities in those APIs based on severity.
- Compare source code with documentation:
Many API vulnerabilities happen when an API is coded in a different way than what was documented. That means you cannot identify a risk or vulnerability solely from looking at the documentation. You also cannot configure security controls without validating the documentation.
Rather than rely solely on API documentation, Checkmarx API Security does two things:
- First, it identifies APIs that exist in source code but do not exist in documentation. Providing this inventory of undocumented APIs gives you a complete view into your shadow and zombie APIs, regardless of where they are or whether they are behind a WAF.
- Then, we look at the documented APIs and compare how the API is written in code against its documentation to identify data discrepancies that can lead to a vulnerability.
- Make it easier for developers to fix problems before APIs go into production
Checkmarx API Security integrates with Checkmarx SAST to scan source code as it’s checked in. When vulnerabilities are found, Checkmarx automatically creates bug tickets (such as with JIRA) for that vulnerability. This puts the vulnerability in a context that developers understand and are used to fixing as part of their day-to-day routine – the software bug.
Security teams can identify shadow APIs and track vulnerabilities discovered as the API code is first checked in. This allows security to work with closer developers earlier in the SDLC, to properly document APIs and address any vulnerabilities found.
So, what’s the bottom line?
Taking a true shift-left approach can give security teams complete visibility into their API footprint. By integrating with the SDLC during the design, coding, and check-in phases, Checkmarx API Security offers an easier way to keep up with the continuous change in the API environment – and enable your developers to fix any problems found.
Figure 5: taking a true shift-left approach to API security allows you to discover all your APIs
But perhaps the final advantage is that, with Checkmarx, this can be done without the need for any additional tooling. You don’t need to purchase, deploy, and manage an API-specific solution that doesn’t solve the entire problem. Instead, you can find your shadow and zombie APIs with the same AST solution you already have and are already using to find and fix vulnerabilities.
To find out more, go to https://checkmarx.com/product/api-security
