Let’s face it – Application Programming Interfaces or APIs are a foundational part of modern applications. They are just as crucial as home-grown code, open-source packages, frameworks, and libraries in your application’s architecture.
One of the questions I have heard for years while working with commercial enterprise applications is: do you have an API? If you don’t have a full-function API, then people think there is something wrong with your application and it is not enterprise-grade.
APIs have access to all sorts of functionality and data. Nobody wants to reinvent the wheel for additional data or functionality in their applications. The problem is that it is very easy to access sensitive data from another application using an API. If that API is collecting too much sensitive data or is not authenticated correctly it is an easy target for hackers to leverage.
People always talk about APIs, but what exactly is an API? A simple definition of API is “a connection between computers or between computer programs. It is a type of software interface offering a service to other pieces of software.”
In simplistic terms, APIs allow you to consume or share functionality and data between applications. This capability is very powerful as it provides your applications with functionality and data they would otherwise not have. But to quote Spiderman, “With great power comes great responsibility.”
OWASP to the Rescue
To put some order and guidance to the explosion of API use, OWASP came out with the OWASP API Security Project. It provides API usage guidance and an API Security Top 10 list of risks similar to the well-known OWASP Top 10 list for web application risks.
If you read through the list of items in the OWASP API Top 10 list, there is a common theme.
Most items on the list are associated with misconfigured authorization and authentication or overly broad access to data or functionality. The focus of the list is the proper usage of APIs associated with the applications they communicate with and not the applications themselves.
APIs are easy to use and implement – so they are being used more than ever. The problem is that even though they are easy to implement, misconfigurations are very common. You may get the functionality you want from an API but if not configured correctly you may be opening yourself up to unknown risks.
API Security Solutions
In the past few years, there has been an explosion in commercial API Security solutions (obviously). Companies like NoName and Salt Security have great products that help companies automate the discovery and remediation of API Security Risk.
The type of things that these solutions are great are:
- API Discovery
- Prevent API Attacks
- Protect against Sensitive Data Exposure Through APIs
- API Security Metrics and Analysis
- Compliance reporting associated with APIs
- Misconfigured API Authorization and Authentication
The Problem with API Security Solutions
Just like other Application Security Testing (AST) solutions, API Security solutions only look at one component of the application architecture.
For example, SAST solutions look at uncompiled code, SCA solutions look at open source packages, DAST solutions look at the running application from the outside in, and IAST solutions look at the running application from the inside out.
Now you add API Security Solutions to the mix, and you have five data sources associated with risk and security in your applications that need to be categorized, prioritized, and remediated.?
An additional data source = more places you need to look to get information about your applications and APIs. This sprawl of tooling causes confusion and extra work associated with trying to complete the picture.
Complete visibility is needed when using APIs
API Security Solutions are excellent at what they do – finding security issues with the usage and configuration of APIs.
They are not good at understanding the architecture or context of the applications they are communicating with.
A stupid analogy is that APIs are like the delivery truck delivering goods between two factories. You want to ensure the trucks are working properly, secure, operating safely, and transporting the correct goods. The problem is that you have no idea how the goods were created and got on the truck in the first place or what happens to them when they are removed from the truck.
Bionic’s ASPM Solution Provides Complete Visibility
Bionic’s ASPM solution understands the full context of API usage associated with the entire application architecture, not just the APIs the application leverages. Bionic does this by reverse-engineering the deployed application artifacts to map every application service, associated data flows, and all third-party communication.
The context that Bionic provides to API Usage
- Does an API communicate with an application service that has a critical CVE
- Are there misconfigured secrets management at the code level of the application?
- Application architecture drift that would impact API usage
- Dynamically updated SBOM for the entire application architecture, including APIs
- Visibility into data stores with sensitive data
- Prioritization of remediation efforts based on multi-level risk scoring
Why should I care?
Like SAST, SCA, DAST, and IAST, API Security provides valuable information about the risk and usage of one aspect of application architectures. The problem is that these solutions look at the risk of a specific component of an application and not the entire architecture. How do you quantify and prioritize remediation of the security risk and misconfigurations without understanding how the whole application architecture works together.
ASPM provides you with the information and context you need to identify and fix security and architectural risk quicker and more efficiently.
Check out this demo of ASPM to see how we visualize everything in our map differently than other API security tools: