APIs are quickly becoming the largest attack surface in applications. API security solutions help an organization improve its security posture by finding and locking down APIs wherever they may reside, either blocking attackers or offering information to help IT teams better protect the APIs.
With the growing number of APIs spread across the entire corporate infrastructure, protecting those APIs is becoming as important as protecting web properties hosted across the same infrastructure. But while—thanks to increasing education and higher-quality security tools—the task of protecting web pages (even dynamic web pages) is now routine for most organizations, the same can’t be said for APIs. We are still learning about protecting our API infrastructure, and even when we do a great job with one API or API family, similar APIs might not have the same level of protection. Indeed, many enterprises are at the very start of their API security journey—discovering exactly what APIs are hidden within their infrastructure.
API security products were generally developed before API use burgeoned to the extent we see today, and early targeting was simple. Those products were based upon the idea that it is asking for failure to insist developers secure the code they write, and there is a lot of truth in this original reasoning. Most developers do not knowingly create insecure code, so if they develop code with vulnerabilities, it is likely because they are unaware of what vulnerabilities a given API might suffer from. Once API security was in use, though, IT quickly discovered a new reason to use a security product: Some vulnerabilities are far easier blocked in the network than in each and every application.
The idea that some attacks are best blocked in the network before access to the API occurs, along with the presence of numerous undocumented APIs that likely exist in organizations, has spurred customers to demand that these products have a way to detect APIs running on the corporate network. For this analysis, a corporate network is the new extended network that includes data center, cloud vendor(s), and hosting. In some environments, it can also include software as a service (SaaS), though few enough SaaS environments include the ability to develop and deploy APIs.
Just as the API security solution must have a way to learn about APIs, it also must be able to protect them once it finds them. API security started under SOAP, when APIs first saw broad adoption, but soon had to adapt to protect REST, which is the primary area of protection today, although new API standards are growing in popularity. Which standards can be protected and how deep that protection goes are important considerations when evaluating API security products. In this analysis, we will also consider whether the product protects the data layer, and what level of protection the data layer receives.
API security is one of the most important aspects of security in the modern enterprise. There are ever more APIs deployed daily, and many organizations have not kept up with API-specific security. For those just starting to consider API security, our report “Key Criteria for Evaluating API Security Solutions” will help you to understand the market and learn what you need to look for when evaluating these products. For those who do not have either web application security or API security, a look at our 2022 Radar report for Application and API Security is also a good idea, as those products generally cover both API security and web application firewalls (WAFs).
This GigaOm report is one of a series of documents that helps IT organizations assess competing solutions in the context of well-defined features and criteria. For a fuller understanding, consider reviewing the following reports:
Key Criteria report: A detailed market sector analysis that assesses the impact that key product features and criteria have on top-line solution characteristics—such as scalability, performance, and TCO—that drive purchase decisions.
GigaOm Radar report: A forward-looking analysis that plots the relative value and progression of vendor solutions along multiple axes based on strategy and execution. The Radar report includes a breakdown of each vendor’s offering in the sector.
Solution Profile: An in-depth vendor analysis that builds on the framework developed in the Key Criteria and Radar reports to assess a company’s engagement within a technology sector. This analysis includes forward-looking guidance around both strategy and product.
To better understand the market and vendor positioning (Table 1), we assess how well API security solutions are positioned to serve specific market segments.
In addition, we recognize three deployment models for solutions in this report: cloud-only, SaaS and multicloud, or local.
Table 1. Vendor Positioning
Building on the findings from the GigaOm report, “Key Criteria for Evaluating API Security Solutions,” Table 2 summarizes how each vendor included in this research performs in the areas that we consider differentiating and critical in this sector. Table 3 follows this summary with insight into each product’s evaluation metrics—the top-line characteristics that define the impact each will have on the organization.
The objective is to give the reader a snapshot of the technical capabilities of available solutions, define the perimeter of the market landscape, and gauge the potential impact on the business.
Table 2. Key Criteria Comparison
Table 3. Evaluation Metrics Comparison
By combining the information provided in the tables above, the reader can develop a clear understanding of the technical solutions available in the market.
This report synthesizes the analysis of key criteria and their impact on evaluation metrics to inform the GigaOm Radar graphic in Figure 1. The resulting chart is a forward-looking perspective on all the vendors in this report, based on their products’ technical capabilities and feature sets.
The GigaOm Radar plots vendor solutions across a series of concentric rings, with those set closer to the center judged to be of higher overall value. The chart characterizes each vendor on two axes—balancing Maturity versus Innovation, and Feature Play versus Platform Play—while providing an arrow that projects each solution’s evolution over the coming 12- to 18-months.
Figure 1. GigaOm Radar for API Security
For this Radar, vendors that are positioned in the Maturity quadrant take a more traditional approach to API security and a more methodical rate of change to the base product, while placement in the Innovation quadrant suggests newer approaches (like AI/ML) and a more rapid rate of change to the base product. The Feature versus Platform-Play range spans from point solutions addressing one aspect of API security (like automated security testing) to solutions that attempt to address several API security concerns via multiple features or products.
As you can see in the Radar chart in Figure 1, Salt Security and Traceable are firmly in the Leaders circle, and comfortable with the product they’ve produced, focusing on improving current features. 42Crunch and Neosec are also in the Leaders circle, but are developing new functionality, with 42Crunch already having a broad offering while Neosec today is more feature focused but broadening its offering as it moves toward a platform approach. Wib is a new company, but brings a strong enough offering to skip straight into the Leader category. Its rate of change is slower, simply because the company will be perfecting the offerings it has released within a short time period. Noname is relatively new, and debuts as a Challenger, with momentum for new features and products that is reflected by the length of the arrow. StackHawk and APIsec are more feature-focused products—preferring to solve one piece of the API security puzzle well—and are moving forward with their chosen solutions.
The GigaOm Radar weighs each vendor’s execution, roadmap, and ability to innovate to plot solutions along two axes, each set as opposing pairs. On the Y axis, Maturity recognizes solution stability, strength of ecosystem, and a conservative stance, while Innovation highlights technical innovation and a more aggressive approach. On the X axis, Feature Play connotes a narrow focus on niche or cutting-edge functionality, while Platform Play displays a broader platform focus and commitment to a comprehensive feature set.
The closer to center a solution sits, the better its execution and value, with top performers occupying the inner Leaders circle. The centermost circle is almost always empty, reserved for highly mature and consolidated markets that lack space for further innovation.
The GigaOm Radar offers a forward-looking assessment, plotting the current and projected position of each solution over a 12- to 18-month window. Arrows indicate travel based on strategy and pace of innovation, with vendors designated as Forward Movers, Fast Movers, or Outperformers based on their rate of progression.
Note that the Radar excludes vendor market share as a metric. The focus is on forward-looking analysis that emphasizes the value of innovation and differentiation over incumbent market position.
42Crunch Developer-First API Security Platform
42Crunch is primarily a SaaS solution with a locally installed portion hosted in Docker for runtime reporting. The product’s goals are to shift left and cover the important parts of API interfaces, allowing network security and vulnerability management to cover incoming and back-end issues. This enables 42Crunch to help shift API security issues left. Central to the protection is a positive security model that allows only designated traffic through. While it definitely adds security, this method is more prone to breaking applications, simply because it is more rigid than a negative security model that blocks only what it is told. 42Crunch believes that basing the positive security model on API definitions alleviates this concern. If your organization leans more toward security first, looking into this option and its implications is worthwhile.
At the time of this analysis, 42Crunch supports only REST APIs, but support for both AsynchAPI and GraphQL is in development and close enough to release to warrant a mention here. Potential customers should check the status of these standards if either is important to the organization. The product currently has a discovery tool supporting APIs defined in Swagger files, but not network discovery.
42Crunch combines security functionality at the design, build, and deployment stages. By protecting only the interface portion of APIs, it allows rapid scanning during the build step. For organizations that already have a vulnerability management system in place, this is a good solution—vulnerability management will do deep scans of source code while 42Crunch analyzes the interfaces as defined in OpenAPI or Swagger files. However, for customers who don’t yet have a code-scanning product, it’s not so great. Nothing will scan the actual source code, which is often the dangerous part of an API. A similar design was chosen for API protection; what 42Crunch calls an “API Firewall” sits in the traffic stream for a given API and enforces policies—starting with positive security —upon the API. This system allows 42Crunch to detect and prevent attacks before they actually touch the API, and is implemented before the API reaches production.
For data protection such as JSON parser protection, JSON Web Token protections, and data leak prevention, 42Crunch bucks the current trend of moving to AI/ML analysis to detect issues. Instead, the company offers an impressive list of design/build policies that can be applied to an application and help to lock it down beforehand rather than having to respond to issues in real time. As with most policy engines in information security, this solution is more proactive for known problems and less responsive for as-yet-unknown issues. How this policy-during-build approach fits a given organization’s security posture is best determined by the reader.
Strengths: Runtime protections stand out with 42Crunch because its API protection offering takes a unique approach to the problem—what is described as a “micro firewall” based upon the API specification. In terms of overall suitability, 42Crunch checks the boxes better than most products; for some organizations, the design/build-time approach used throughout the 42Crunch offering will be a strength.
Challenges: If 42Crunch’s design choices don’t fit an organization, it will seem far inferior to what our ratings would suggest. Basing security on a positive security model is unlikely to be more popular today than it has been historically, even though it could be argued that it’s better. By the same token, scanning API interfaces but not the code behind them only works well in organizations with static analysis of source code already in place.
APIsec
APIsec approaches API security from a pure testing perspective. Using a SaaS system that evaluates APIs, the solution builds a test suite specific to a given API, then exercises that test suite. APIsec currently protects REST and GraphQL APIs. Ingestion is handled with active insertion, and there is an automatic discovery mechanism, but it is based upon log scanning and not traffic. Since logs will contain traffic information, this may be good enough for a given organization, but is not the standard most vendors are implementing.
There are several implications of the APIsec approach. Ingestion, analysis, and testing of APIs all occur without needing access to the running application. This makes APIsec more proactive in many situations, but does not offer any form of runtime protection in the usual sense. The product attempts to lock down your APIs before they are deployed, so that runtime protections are not needed. This implies that AI/ML is not used to detect anomalous behavior in the APIsec product. If you’re looking for that sort of protection, you should consider other options, either as a replacement or to complement APIsec.
Given that the product generates thousands of tests and accesses information from across the company’s customer base to consider what new tests an application may need, the broad coverage this solution provides may be what a given organization needs to protect its APIs.
APIsec’s approach allows absolute shift-left, since scanning happens during development, and protections are aimed at safeguarding the application during deployment. To support this shift-left action, APIsec has a number of integrations with CI/CD tools. APIsec fits into the CI/CD pipeline seamlessly, with scans being kicked off by most build tools, and results being populated into most of the popular issue-tracking products.
Strengths: Finding issues before they get to production is the goal of APIsec, and it succeeds on that score. Integrations are also a standout feature for the product. APIsec would be a great fit as an adjunct to other products in the API security and application and API protection spaces.
Challenges: Static analysis, no matter how good, is only a part of API security. Changes in the landscape, new and inventive attacks, and always-on environments almost demand that API security products have a runtime component, which APIsec lacks.
Neosec
Neosec is a SaaS-based API security product with additional managed services available. The system is implemented as an adaptation of extended detection and response (XDR), monitoring API traffic to detect and protect APIs in the corporate environment.
Of all of the products we looked at for this analysis, Neosec has the most thorough list of import and detection points for APIs. Many customers start their API journey with detection, simply because most information security departments don’t know what is out there across the entirety of the organization. Neosec meets this need, with the ability to auto-detect and import from development tools, DevOps tools, cloud services, Swagger, and more.
The Neosec solution is based on advanced behavioral analytics. This enables more dynamic protection of APIs—including both business logic and data—than most solutions provide, but the solution lacks the absolute lock-out capabilities basic to rule-based systems. Which is a better fit for a given organization should be a key decision point for evaluators.
Because Neosec auto-detects APIs, where the API resides, and whether it’s north/south, east/west, B2B or B2C is not that important. Placed and set to protect, Neosec can detect and protect all of the above.
One area we looked at for this analysis was how reporting was protected. The huge volume of API data—including vulnerability data–collected is a juicy target, so we asked how access to that data was limited. Neosec protects it with standard role-based access control (RBAC) in front of reporting.
Neosec’s threat hunter managed service, ShadowHunt, is an addition to the core product that provides professionals the ability to track API threats as they move through a system and help IT secure APIs. If an organization is short-staffed, or lacks experience in threat-hunting correlations, this service may be just the thing to fill the gaps and help staff gain experience.
Strengths: The list of API standards and import mechanisms available in Neosec is impressive. Finding out what needs to be protected is a key reason these products are adopted, and Neosec’s auto-detection feature easily handles this. The ShadowHunt managed service is also a huge benefit to organizations that don’t have the time or talent to fill this role.
Challenges: Neosec does not support static scanning methods, and would say that they are not necessary in its environment. We think that every tool in the toolbox is necessary when protecting what is rapidly becoming the largest cyber attack surface. The ability to monitor and block is nice; the ability to find weaknesses early with static scanning is nice too, and that’s the part we found lacking.
Noname Security
Noname Security’s solution comprises three components: Posture Management (for inventory and scanning), Runtime Protection (uses AI/ML for real-time monitoring), and Active Testing (a suite of on-demand security tests for APIs).
Of the products we looked at, Noname has the broadest support for API standards, including SOAP, REST, GraphQL, XML-RPC, gRPC, and JSON-RPC, so it should be considered by any organization that needs more than simple REST support. The product also offers excellent discovery capabilities, using both definition files and auto-discovery to get all of an organization’s APIs into the system.
The product’s static analysis of the API source code is less impressive, though, because the product focuses on discovering, testing, and protecting APIs more than on scanning their underlying source. Still, vendors in adjacent markets can offer extensive static analysis and can help fill this gap and complement Noname’s impressive solution set.
The Runtime Protection AI/ML component is geared to protect not just the interface, but the payload as well, a feature that’s more important than is generally recognized. While the API is the point of access, all of the bits interesting to ne’er-do-wells are in the payload.
Finally, the test suite offered by Noname can be connected into an organization’s DevOps toolchain, making shift-left of API security simply a matter of deployment and setup. The ability to run the tests on build, then feed the results into defect-tracking tools like Atlassian Jira, is huge for customers attempting to get DevSecOps off the ground.
Monitoring is handled with mirroring. Whether this is a strength or a weakness is very much an organizational question: while mirroring does not impact performance in any way (an increasing concern as the number of APIs in the average call chain continues to grow), it does send data to a destination it was not intended for, and companies will have to check on whether that will affect compliance. Noname minimizes the issues this extra step creates by allowing customers to send this mirrored data to an internal server or their SaaS, so any concerns become implementation issues for evaluators to be aware of as opposed to showstoppers.
Strengths: Noname takes a broader approach to protection than most of its competitors, offering discovery, AI protection, and monitoring all in a single product. Protecting both API and associated payload (JSON, XML, and so forth) is a big deal, and is increasingly something organizations will want in their API protection products.
Challenges: With all of the solution’s included capabilities, it feels off-putting to not have access to static scanning capabilities. But vulnerability management products do offer that capability, so lack of it may not be a problem if such are deployed.
Salt Security
The Salt Security API Protection Platform is a SaaS-based solution that offers discovery, testing, real-time monitoring, and shift-left functionality. It can also use an on-premises processing appliance to keep corporate data on the corporate network, and send only metadata and attack traffic—information necessary for API protection—out to the SaaS.
The Salt solution is one of the few that attempts to cover APIs in every currently available way. With static API interface design analysis, dynamic ingestion from a variety of network sources, real-time monitoring, API drift analysis, and advanced data protection, there are few gaps in the product’s protection.
We would like to see deep integration with code scanning. The API definition analysis and real-time AI/ML are great, but simple mistakes in an API design won’t necessarily be found in the Swagger files, and are easy to fix if discovered. There are a number of tools that handle static analysis, and we recommend one of them be deployed with Salt Security’s solution. This company is not the only vendor whose product would benefit from static analysis, but the completeness of this solution makes us feel that should be the next step.
Runtime protections are very thorough in the Salt Security product, offering long-term monitoring once anomalous behavior is detected. This allows Salt to say “Well, this user just requested a ton of personally identifiable information (PII) and we blocked it. We’ll watch them to make sure it was just user error and not an attack.” This functionality both reduces alerts for innocent behavior and allows for teams to detect long-tail attacks by watching what has been flagged in the relatively recent past. Though it was not part of our evaluation, this functionality might also help IT discover confusing APIs or UIs by noting when a large number of people are using an API in unexpected ways.
The system monitors API calls more deeply than most of the products in this analysis, looking at and categorizing parameters, payload fields, users, call chains, and more. This information is made available to users, and IT management can use RBAC to control access to this data at a granular level—something not all products offer at this time. All of that data, combined with metadata about attacks on other customers and with an AI/ML engine to help make sense of the data, makes the product a formidable monitoring and proactive protection tool.
Strengths: The ability to track attacks over time, watching as they develop before notifying IT, is a massive strength. The breadth of protection is also notable, reducing the number of solutions an organization will need. Finally, the on-premises component that keeps corporate information on corporate networks while still offering protection to APIs on those networks is huge. Compliance needs won’t be circumvented by shipping customer data off-site, and yet that data is still protected.
Challenges: The solution lacks the ability to statically analyze more than just the API definition. Reporting capabilities are also limited, though we were assured that the issue was being resolved.
Stackhawk HawkScan
HawkScan is a container-based (or command-line-based) scanning tool that performs comprehensive analysis of APIs by crawling and pretending to attack them. The system does not do static analysis and it does modify data, so it’s not suitable for production use. Standard Stackhawk deployments run tests from development or DevOps tools, making turnaround time fast.
StackHawk runs from a single docker image or command-line tool, reporting results to a SaaS component. The tool focuses on dynamic scans, finding weaknesses in APIs by trying to abuse them. This is resource-intensive, can be time-consuming, and the tool can test only what it is told about. But it is good at what it does.
Users can customize scans to focus exclusively on testing vulnerabilities in a subset of technologies. For example, the tool would normally attempt exploits against an API that are based on all languages (there are several different technology areas that can be covered, including language, database, and framework). However, users can tell it, “We developed in .NET, so test only against that.” This directive can reduce both scan times and false positives.
Along the same lines, the product can be given API definitions—Swagger, GraphQL, or SOAP definitions, for example—and told to use those. This reduces overall scan times by reducing discovery times.
There is no static analysis, but there is integration with Snyk to provide that functionality. There are also integrations with most enterprise-class defect-tracking systems to allow the tool, or operators, to put issues directly into the defect-tracking system. Finally, integration with CI/CD tools is expansive, allowing kick-off from build.
The product offers no runtime protection, instead focusing on protecting APIs before they get to production. As already noted, we believe that an organization should have and use all of the tools available to protect its APIs, and users of HawkScan will need some other product to handle monitoring and runtime protection.
Strengths: The ability to point the tool at an API root and tell it “go” to examine all of that application’s APIs and API variants without having to feed in definitions—or take special steps to limit what the tool can see—is huge. This allows a team to deploy StackHawk for DevOps usage, while competitors would require a corporate decision or special steps to keep the product from viewing all APIs.
Challenges: The lack of static scanning is compensated for with integrations, but the lack of real-time monitoring and reporting is not and will require another tool. Also, as payload security becomes more and more of an issue, this solution may fall behind if payload functionality is not implemented. Stackhawk assures us that this will not be an issue in the future, but evaluators should consider what is available at the time evaluations are performed.
Traceable
Traceable AI’s offering can be purchased as a local or SaaS deployment. The toolset includes API Risk Posture Management, API Vulnerability Management, API Attack Protection, and assistance with API Threat Hunting. Traceable enables discovery and importing of APIs; protection from attacks, both known and unknown; and assistance in tracking down the trails that lead to a successful attack. The product supports SOAP, REST, GraphQL, and gRPC, among other protocols.
The solution merges the best of the available approaches to import APIs, with auto-discovery augmented by the ability to feed in specific APIs. It places all discovered and imported APIs into a catalog that IT can then access to see the extent of its API footprint. Each API endpoint is evaluated and rated from the risk standpoint and grouped based on services, domains, and API usage attributes.
There is also a mechanism that compares the API definition against current usage patterns to detect API drift and help secure APIs with regard to actual use versus definition changes. In this marketplace, tools don’t generally have deep data exfiltration capabilities. Such deep monitoring of payloads is usually handled by application and API protection products. Traceable is an exception. However, while it offers data exfiltration assistance, this requires specific deployment scenarios (the tools inline are needed to detect the activity and block the connections).
In addition to runtime protection, Traceable offers active security testing and passive detection of API vulnerabilities that can be used in pre-production environments independently or in conjunction with the existing CI/CD tools.
The ability to deploy this solution entirely within the corporate network is a major boon for organizations in highly regulated environments and those in markets where the search for competitive intelligence may be hostile. Knowing that the entire solution is under the control of corporate IT is important in some scenarios. Though SaaS vendors take advantage of the volume, cross-company correlation, and long-term collection that SaaS can facilitate, this activity requires data to leave corporate control. If control of corporate information is an issue for an organization, Traceable is definitely an option.
Traceable offers both policy- and AI-based protection of the running application, and includes both alerting and blocking modes. This is really the best approach to runtime protection, as policy protects against a large set of known attacks, while AI/ML can watch for anomalous behavior that might indicate a previously unknown attack.
Strengths: The breadth of Traceable’s solution—both in discovery and in protection—is more complete than most, if not all, vendors in this space. Its API catalog and threat-hunting capability are also major strengths.
Challenges: As with some other vendors, the lack of static analysis beyond API definitions feels incomplete as weaknesses in underlying source code won’t be obvious from a scan of the API definition. While vulnerability management products can fill this gap, we would like to see integration or implementation that makes it part of the API security solution.
Wib
The Wib solution consists of a core platform and Fusion Engine that ingests data from a variety of sources to offer API intelligence and protection. The platform is available as either a local or SaaS offering and covers APIs from development through runtime—pretty close to the software development lifecycle (SDLC). Wib is a new entrant in this space, but it offers a comprehensive solution.
Local deployment options are important to some organizations and industries as they allow IT to maintain control of data and resources. Moreover, API source code scanning is supported by some other vendors, but not most. We think this will likely be a differentiator for Wib for a good long while, as many vendors in the space like to say network monitoring for APIs is “different” and can’t be handled by general API protection solutions, and they leave API source code analysis to general SAST solutions. Wib sees both as having unique elements, and protects APIs with an API-centric solution both in the source and on the network.
For starters, the solution scans not only the API source code, but also the API interface. Then it scans APIs in the test phase and builds attack simulations based on the APIs available, and, finally, it watches behavior at runtime to learn normal API interactions so runtime anomalies are easier to detect. This functionality is provided for any API standard whose transport mechanism is HTTP, which is the vast majority. However, specialized functionality for specific API standards is not yet present, so if an organization relies heavily on a non-REST API standard, evaluation of this solution for suitability to task is recommended.
This three-pronged approach—getting information from code analysis, testing, and production—is central to Wib’s overall strategy toward solving the API security problem. It means that the product protects during development with source code scanning, during build with automated testing, and during runtime with traffic analysis directed at both shadow API discovery and monitoring for abnormal behavior.
Strengths: Wib’s greatest strength is source code analysis with an eye toward API weaknesses. In addition, Wib’s platform provides automatic API documentation to create up-to-date documentation, as well as snapshots of changes to APIs and their risks every time they see a commit to code.
Challenges: As a newcomer, Wib is a relative unknown. Normally challenges are about technology, but there is so little information out there about this solution that no matter the technology, the company may well struggle. Moreover, the lack of specialized functionality to protect specific API standards is a concern. There are different issues involved in protecting GraphQL versus protecting REST, for example.
The massive growth of API adoption and new development methodologies like microservices leave the API security market in flux. Vendors are attempting to achieve the same goal, but they are taking different approaches.
This is both good and bad for customers. It creates more options but increases the likelihood that a given solution or vendor may fall by the wayside. This introduces a bit of risk into buying API security products at the moment.
Our recommendation is to look first at products that offer a broad solution set. The most complete products offer discovery, static analysis, dynamic testing, and protection, while others focus on one or two features and aim to do them really well. Keep in mind that these products are not normally being installed in greenfield scenarios. It’s likely there are already security products deployed, and there might be significant overlap. We recommend choosing a solution that fits into your existing architecture. For example, very few of these solutions perform static scans of source code because your developer security product is probably already handling that task. Most of them will perform static scans of API definitions, however, because static application security test (SAST) scanners generally do not yet cover API definitions.
After years of change and growth, this market, like so many others, is facing increasing competition from adjacent markets. The first question evaluators need to answer is, “Is this the correct market to meet our needs?” Overall application security—including static, dynamic, and interactive scanning—can be found in developer security and vulnerability management tools, while active protections like WAF and AI monitoring of connections can be found in application and API security (AAP/AAS) products.
This market is separate because it is all about securing APIs, and the tools involved are separate and distinct from tools like WAF. A good rule of thumb is this: if an organization has a WAF that they are happy with already deployed, then augmenting it with an API security product is a great choice. If an organization is just getting into application and API security, then an AAS/AAP product is a better option, as it brings a variety of protections for applications and APIs in a single product. While there is some monitoring and testing overlap between this market and development security, these products will augment any development security solution well.
At the time this analysis was performed, most customers were still looking for API inventory and discovery products that would give their IT departments an idea of what is on their networks, so they can take the next step and start protecting those assets. For organizations where this is the motivator, look for solutions that offer more than API definition import (via OpenAPI file and so on), because those are already documented APIs. Other forms of discovery are required for shadow APIs.
Don MacVittie has more than 25 years of technology industry experience, working in nearly every IT position in a wide variety of organizations – from tax software developer to insurance industry strategic architect and IT manager at a utility. Don has been an analyst for the last decade, is named on two networking patents, and has co-authored ANSI and ISO standards in geographic information systems. His love is learning about technology, and he will happily discuss technology with anyone.
GigaOm provides technical, operational, and business advice for IT’s strategic digital enterprise and business initiatives. Enterprise business leaders, CIOs, and technology organizations partner with GigaOm for practical, actionable, strategic, and visionary advice for modernizing and transforming their business. GigaOm’s advice empowers enterprises to successfully compete in an increasingly complicated business atmosphere that requires a solid understanding of constantly changing customer demands.
GigaOm works directly with enterprises both inside and outside of the IT organization to apply proven research and methodologies designed to avoid pitfalls and roadblocks while balancing risk and innovation. Research methodologies include but are not limited to adoption and benchmarking surveys, use cases, interviews, ROI/TCO, market landscapes, strategic trends, and technical benchmarks. Our analysts possess 20+ years of experience advising a spectrum of clients from early adopters to mainstream enterprises.
GigaOm’s perspective is that of the unbiased enterprise practitioner. Through this perspective, GigaOm connects with engaged and loyal subscribers on a deep and meaningful level.
© Knowingly, Inc. 2022 “GigaOm Radar for API Security” is a trademark of Knowingly, Inc. For permission to reproduce this report, please contact [email protected].