What Is API Security?

API is the abbreviation for application programming interface. Just like you would protect your basic information, like the password tied to your user identity on social media, it is equally important on the back end to protect API access, so that identifiers like API keys and API calls do not get misused.

It’s not surprising that APIs represent an increasing security risk, because any web application or web service available is almost certainly supported in some way by an API. From mobile applications and Internet of Things (IoT) devices to internal applications, cloud-based customer services, and microservices architectures, APIs make your business communication and transactions possible.

Consequently, web API security and API management must be a critical priority for your IT teams throughout the entire lifecycle of your APIs. But protecting APIs from security threats can be a complex challenge, thanks to cloud migration, modern DevOps practices, and constantly evolving APIs.

API security is a systematic approach for protecting the APIs that organizations use to support their business processes. These may include:

• APIs that are implemented to make functionality and data easily accessible by customers or business partners
• APIs consumed by business partners
• APIs that are implemented and used internally, to make application functionality and data available to various systems and user interfaces in a standardized and scalable manner

An effective API security strategy must include systematic techniques for:

• Assessing risk and potential impact
• Executing appropriate mitigation measures

The first step in assessing risk is building an inventory of all sanctioned and unsanctioned APIs published and used by the organization. This inventory should include attributes such as:

• Data classifications, which at a minimum distinguish between “not sensitive,” “sensitive,” and “very sensitive” data
• Risk indicators, such as API vulnerabilities and misconfigurations

These are the essential building blocks for measuring impact and prioritizing mitigation efforts.

API visibility and risk mitigation measures must consider a diverse collection of possible threats, including:

• Detecting and preventing the use of unsanctioned “shadow APIs”
• Identifying and remediating API vulnerabilities and misconfigurations that malicious actors could potentially exploit
• Preventing instances of API misuse, like business logic abuse and data scraping

Identifying and mitigating these and other API security risks requires security controls that are sophisticated enough to address this complex and fast-evolving threat landscape. But equally important is finding ways to extend API security practices into non-security workflows that affect API security posture, such as software development and documentation.

APIs, or application programming interfaces, are a key part of modern web development. But with great power comes great responsibility, and when it comes to APIs, that responsibility is security. API security is all about protecting the interfaces between applications. Without proper API security, sensitive data could be exposed, systems could be compromised, and services could be disrupted. Basically, API security is what keeps the bad guys out while letting the good guys do their work.

Two fundamental aspects of API security are authentication and authorization. Authentication is the process of verifying the identity of a user, device, or system. It’s like checking an ID at the door of a club — you need to make sure that the person trying to get in is who they claim they are. Authorization, on the other hand, is about determining what a verified user can and can’t do. Just because someone is allowed in the club doesn’t mean they can go behind the bar and pour themselves a drink. In the API world, authentication and authorization might involve techniques like API keys, tokens, or OAuth.

Another important aspect of API security is input validation. This involves checking that the data sent to an API is valid before it’s processed. Think of it like checking tickets at a movie theater — you wouldn’t let someone in with a ticket for a different movie, right? In the same way, input validation helps to prevent malicious data from getting into an API and causing trouble.

API security is one of the fastest-growing priorities for security executives. But it’s also arguably one of the least understood. The evolution of APIs from implementation detail to a strategic enabler of innovation has been a rapid one. As a result, many security teams are scrambling to increase the sophistication of their API security strategies and practices. APIs are enabling commerce, but they also carry sensitive data.

The following is a collection of topics that security leaders and practitioners can use to increase their foundational knowledge about API security.

A web API is a programmatic interface consisting of one or more publicly exposed endpoints to a defined request–response message system, typically expressed in JSON or XML, which is exposed via the web — most commonly utilizing an HTTP-based web server.

When they hear “API,” what most people think of is a web API. It’s a collection of endpoints. Endpoints consist of resource paths, the operations that can be performed on these resources, and the definition of the resource data (in JSON, XML, protobuf, or another format).

The term is useful to differentiate web APIs from other APIs, such as those exposed by the operating system or by libraries to applications running on the same machine. But we all take “APIs” to mean HTTP-based (web) APIs when we talk about enterprise digital transformation and API security.

The four main types of web APIs seen today, defined as being based on HTTP, are:

• RESTful APIs — dating back to Roy Fielding’s doctoral thesis in 2000, representational state transfer is the most common type of web API, typically using JSON (JavaScript object notation) for the data. RESTful APIs are easy to consume by modern front-end frameworks (e.g., React and React Native) and facilitate web and mobile application development. They became the de facto standard for any web API, including those used for B2B. 
• SOAP APIs — SOAP uses the verbose Extensible Markup Language (XML) for remote procedure calls (RPC). It can still be found in legacy APIs.
• GraphQL APIs — the new, Facebook-developed, GraphQL standard provides database access over a single POST endpoint (typically /graphql). It solves a common RESTful API problem — that of requiring multiple calls to populate a single UI page — while introducing other additional problems.
• gRPC APIs — a new, Google-developed, high-performance binary protocol over HTTP/2.0, that used mostly for east-west communication

Business-to-consumer (B2C) APIs are the APIs that power web and mobile applications. They are typically consumed by modern front-end clients to allow end users access to the company’s business functionality exposed by these APIs.

Business-to-business (B2B) APIs are those used by the company’s business partners (other companies), sometimes to provide them with services (these businesses being the end customer), and sometimes to provide value to joint customers (B2B2C).

B2B APIs are fundamental to the enterprise’s digital transformation, as they enable it to streamline how it works with its suppliers, resellers, and other partners, as well as provide a better experience to its customers.

Examples of B2B APIs include:

• Open banking APIs
• Supply chain management APIs
• Electronic invoicing and payments between trading partners

Since the consumers of the APIs differ greatly (user-facing apps consuming B2C APIs vs. partner business applications consuming B2B APIs), the security controls available for securing these APIs also vary.

When it comes to security, the industry has been focused on B2C use cases until fairly recently, but even there, the focus has not been on securing B2C APIs, but rather on securing web applications. The security controls employed for securing B2C web applications translate poorly to securing B2C APIs (e.g., WAF/WAAP) or not at all (e.g., most bot protection solutions).

Protecting B2B APIs is a growing problem. When it comes to B2B APIs, among first-generation vendors there is no dedicated visibility and security solution that covers bulk data access on behalf of shared users (as is the case, for example, in open banking — where fintech companies and financial institutions consensually share customer data). 

People often use the word “API” when what they are actually talking about is a single API endpoint. APIs, sometimes called services or API products, are collections of endpoints that serve a business function. An endpoint, on the other hand, is a resource (or resource path, also known as URI — Uniform Resource Identifier) and the operation performed on it (create, read, update, or delete — operations which in RESTful APIs are typically mapped to the HTTP methods POST, GET, PUT, and DELETE).

These are APIs that an organization exposes to the outside world, primarily to its business partners. For example, banks embracing open banking may expose their accounts to other fintech or financial services organizations via APIs. Healthcare organizations may expose patient records to insurance companies and other medical organizations via APIs. Hospitality organizations may expose their reservation system to travel agents or aggregators via APIs. APIs are the connective tissue that connects organizations. North-south APIs are often considered safe because access is authorized and is authenticated. Typically, this is the fastest-growing and largest volume of APIs and consequently is the largest attack surface for most organizations.

These are APIs that an organization uses internally. These APIs connect internal applications or business units or departments. So long as they are inaccessible from outside the organization, these APIs are considered east-west APIs.

Private APIs, sometimes also referred to as internal APIs, are intended to be used by the company’s developers and contractors. Often a part of a service-oriented architecture (SOA) initiative, private APIs are meant to streamline internal development by enabling different departments or business units to access each other’s data efficiently and effectively.

In contrast, public APIs, also known as external APIs, are exposed to consumers from outside the company. In their most extreme manifestation, as open APIs, they can be freely consumed by anyone. But in any case, they require tighter management and great documentation so that they can be used by engineers outside the company.

It’s important to note that private APIs that can be accessed over the internet are not private after all, in the strict sense of the word. Take for example ACME’s B2C API, used only by ACME mobile apps (developed in-house by ACME engineers). You may be tempted to call this a private API, but since the traffic to this API arrives from the internet (“outside the company”), this API is not private — it’s simply undocumented. Hackers attack such APIs daily, by intercepting the traffic, and by reverse engineering mobile apps to see which APIs they interact with.

API security risks are already one of the most pressing risks faced by enterprise security teams, and the challenge is only growing as more customer interactions and internal business processes make use of APIs.

In short, API usage is exploding, and many security teams are playing catch-up with their API security strategies.

For this reason, API security is quickly emerging as one of the top priorities and areas of concern for IT and security executives. In fact, according to research by Gartner, “By 2022, API abuses will move from an infrequent to the most-frequent attack vector, resulting in data breaches for enterprise web applications.”

While API security and traditional application security are related disciplines, API security is a distinct challenge for two key reasons — the scale and complexity of the problem.

Three factors contribute to the rapid growth of API use:

1. The growing use of microservices, an architecture that mandates the use of APIs for service-to-service communication
2. In the direct-user channel, modern front-end application frameworks such as React, Angular, and Vue use APIs and are displacing legacy web applications that sometimes do not
3. On top of that, APIs are added to address completely new channels as well — channels that are inherently different — for partners, IoT, and business automation

Unlike web applications, APIs are designed to be used programmatically in many different ways, which makes differentiating legitimate usage from attacks and abuse extremely challenging.

An increasing number of organizations use APIs to make business processes and data available bidirectionally with customers and partners. Many understand that business-to-consumer, sometimes known as B2C, APIs power data in websites or mobile apps. However, the network of APIs that are triggered behind the scenes also require API-to-API security. Consider the fintech app you access to look up your financial information that creates business-to-business, aka B2B, API calls from that app to your bank to authenticate you as a user. The network of B2C to B2B API calls shows that you need a holistic approach to protecting all API traffic. The tangled web of B2C and B2B API calls means organizations must also consider API-to-API security.

We recommend that organizations interested in enhancing their API security start with the following 12 best practices:

• Find ways to integrate API security standards and practices with your organization’s software development lifecycle
• Incorporate API documentation and automated security testing into your continuous integration/continuous delivery (CI/CD) pipelines
• Ensure that appropriate and effective authentication and authorization controls are applied to your APIs
• Implement rate-limiting measures to help prevent APIs from being abused or overwhelmed
• Augment rate limiting and other application-level measures with specialized gateways and/or content delivery networks to mitigate the risk of distributed denial-of-service (DDoS) attacks
• Make API security testing an integral part of your broader application testing processes
• Perform continuous discovery of APIs
• Implement a systematic approach for identifying and remediating common API vulnerabilities, including the OWASP API Top 10
• Use signature-based threat detection and prevention as a baseline level of protection against known API attacks
• Augment signature-based detection with AI and behavioral analytics to make API threat detection more scalable, accurate, business-relevant, and resilient against novel threats
• Ensure that API security monitoring and analysis extend over multiple weeks and API sessions
• Complement API security monitoring and alerting with on-demand access to API inventory and activity data for use by threat hunters, developers, DevOps, and support personnel

The best way to approach API security best practices is by thinking in terms of organizational maturity, using a framework like the one below.

An API vulnerability is a software bug or system configuration error that an attacker can exploit to access sensitive application functionality or data, or otherwise misuse an API.

The OWASP API Top 10 offers a useful overview of some of the most widely abused API vulnerabilities that organizations should attempt to identify and remediate.

The OWASP API Top 10 is an excellent starting point for organizations seeking to improve their API safety and security posture. Its categories cover a wide range of possible API risks. But it’s important to note that the categories included in OWASP API Top 10 are quite broad. So it’s important to drill down and apply focus to the sub-areas in every one of them.

There are also API safety risks that fall completely outside of the OWASP API Top 10, such as the abuse of logic bugs. For example, API attackers frequently attempt to exploit authorization issues (covered by OWASP extensively) as well as abuse logic bugs (not covered by OWASP at all).

APIs can be attacked and abused in many different ways, but some of the most common examples include:

• Vulnerability exploitation: Technical vulnerabilities in underlying infrastructure can lead to server compromise. Examples of these types of vulnerabilities range from the Apache Struts vulnerabilities (CVE-2017-9791, CVE-2018-11776, and friends) to Log4j vulnerabilities (CVE-2021-44228 and friends).
• Business logic abuse: These are the scary scenarios that keep CISOs up at night, as legacy security controls are useless against them. Logic abuse is when a threat actor exploits application design or implementation flaws to prompt unexpected and unsanctioned behavior.
• Unauthorized data access: Another common form of API abuse is exploiting broken authorization mechanisms to access data you should not be allowed to access. These vulnerabilities carry many names, such as broken object-level authorization (BOLA) and insecure direct object reference (IDOR), as well as broken function-level authorization (BFLA). An up-to-date list of vulnerabilities can be viewed on the OWASP API Security Project website.
• Account takeover: After a credential theft or even an XSS attack, an account can be taken over. Once that happens, abuse of even the most well-written and perfectly secured API is possible. After all, if you’re not performing behavior analysis, any authenticated activity is considered to be legitimate usage.
• Data scraping: As organizations make datasets available through public APIs, threat actors may aggressively query these resources to perform wholesale capture of large, valuable datasets.
• Business denial of service (DoS): By asking the back end to perform heavy tasks, API attackers can cause “erosion of service” or a complete denial of service at the application layer (a very common vulnerability in GraphQL, but something that can happen with any resource-intensive API endpoint implementations).

Back-end APIs make it possible for developers to access core application services in a fast and highly repeatable manner. This is particularly important for organizations that make data available through a variety of different user interfaces. One of the most important steps that must be taken to secure back-end APIs is to implement a sound authentication and access model. But it’s also important not to assume that a well-authenticated set of back-end APIs will never be abused.

There have been numerous examples of threat actors exploiting vulnerabilities in mobile apps or web interfaces to cause the user interface to interact with back-end APIs in unexpected and unsanctioned ways. The best way to secure back-end APIs against these and other types of abuse is through the ongoing use of behavioral analytics. Creating models of baseline usage of back-end APIs will make it possible to detect anomalies and take proactive steps to secure back-end APIs against attack vectors that may not have been anticipated during the initial development and implementation process.

Driven by changing market and business requirements, APIs are in constant flux. As new endpoint implementations are released to meet new business needs, fix bugs, and introduce technical improvements, older versions of these endpoints are sunsetted.

Managing the decommissioning process of old endpoints is not trivial. Often, endpoint implementations that should have been deprecated remain alive and accessible — those are called zombie APIs.

The best way to conduct enterprise-wide shadow API discovery is to ingest and analyze API activity log data from the sources providing the broadest coverage. Deploying per-app sensors around every API can provide rich information about the API activity, but by definition cannot provide broad coverage, as legacy APIs or APIs you don’t know about remain in the shadows.

Examples of API activity data log sources include:

• Content delivery networks (CDNs)
• API gateways
• Web application firewalls (WAFs)
• Kubernetes container orchestration

Once the raw data from all available sources is collected, AI techniques can be used to transform it into a human-understandable inventory of all APIs, endpoints, and parameters. From there, additional analysis can be performed to classify these elements and identify shadow APIs that should be eliminated or brought into formal governance processes.

When it comes to internal APIs, it really depends on what you mean by “internal.” We frequently hear people referring to APIs exposed over the internet to their own organization’s web and mobile applications as “internal APIs.” While the documentation for these APIs may indeed be accessible only by company employees and contractors, hackers have become very adept at analyzing apps and reverse engineering the APIs serving them via app disassembly toolkits and proxies such as Burp Suite.

However, if by “internal APIs” you mean east-west APIs that cannot be accessed from outside the organization, then the main threat is reduced to insider threat.

Protect your internal APIs (in the former sense of the word) and your business-to-business (B2B) APIs as you would most APIs: Start by securing your secure software development lifecycle (SSDLC), continue by ensuring authenticated and authorized access; manage quotas, rate limits, and spike arrests; and protect against known signatures with WAFs/WAAPs.

For B2B APIs, due to the sensitive and often bulk nature of the transactions, consider adding — if possible — strict authentication mechanisms such as mTLS.

For both, we recommend you employ behavioral analytics, especially if you have many entities involved, which may make the process of distinguishing between legitimate and illegitimate behavior difficult.

For example:

• How do you know if the API credentials of a specific user have been compromised?
• How would you know if your invoicing API is being abused by a partner enumerating through invoice numbers to steal account data?

Protection of B2B APIs and internal APIs requires business context that cannot be gained by analyzing technical elements like IP addresses and API tokens alone. Using AI and behavioral analytics to gain visibility into business-relevant entities is the only way to understand and manage B2B API and internal API risk effectively. Business context and historical benchmarks for normal use of APIs by specific entities like your users or partners — or even business process entities (invoice, payment, order, etc.) — make it possible to see anomalies that would otherwise go undetected.

Many organizations taking a strategic approach to APIs use API gateways. Examples include Apigee, Kong, MuleSoft, Akamai, AWS API Gateway, and Azure API Management.

Most API gateways have rich integrated security features that organizations should take advantage of — first among those is authentication (and authorization as well, if you can leverage OpenID Connect).

However, merely doing authentication, authorization, and quota management at the API gateway is not sufficient for several reasons:

• The discovery gap of API gateways: API gateways only have visibility and control over APIs that they are configured to manage, making them ineffective at detecting shadow APIs and endpoints
• The security gap of API gateways: API gateways can enforce authentication and, to some degree, authorization schemes, but do not inspect payloads (as do WAFs and WAAPs), nor do they profile behavior to detect abuse

The number of possible API misconfigurations is nearly endless given the wide number of ways that APIs are used. However, the following are some common themes:

Authentication is foundational to securing sensitive data that is made available via APIs. Step one is ensuring that all APIs carrying sensitive data have authentication in place in the first place. But it’s also important to protect authentication mechanisms from brute-force attacks, credential stuffing, and the use of stolen authentication tokens via rate limiting.

Misconfigurations allowing API consumers to bypass authentication mechanisms can sometimes happen, often around token management (for example, some notorious JWT validation issues, or not checking the token scope).

One of the most common uses of APIs is to provide access to data or content, including sensitive information. Authorization is the process of verifying that an API consumer is eligible to access the data they are trying to access before making it available to them. This can be done at the object or resource level (for example, you can access your orders but not someone else’s), or at the function level (as is often the case with administrative capabilities).

Authorization is hard to get right, due to the high number of edge cases and conditions, and because of the various flows API calls can take between microservices. If you don’t have a centralized authorization engine, your API implementation likely includes some of these vulnerabilities, such as BOLA (broken object-level authorization) and BFLA (broken function-level authorization).

There are many possible types of security misconfigurations beyond the authentication and authorization issues mentioned above, including insecure communication (e.g., failure to use SSL/TLS or using vulnerable cipher suites), unprotected cloud storage, and overly permissive cross-origin resource sharing policies.

When APIs are implemented without any limits on the number of calls that API consumers can make, malicious actors can overwhelm system resources, leading to service degradation and full-scale denial of service (DoS). At the very least, rate limits must be enforced on access to any unauthenticated endpoint, with authentication endpoints being of critical importance — or else brute-force attacks, credential stuffing, and credential validation attacks are simply bound to happen.

API attacks are attempts to use APIs for malicious or otherwise unsanctioned purposes. API attacks take many forms, including:

• Exploitation of technical vulnerabilities in API implementations
• Use of stolen credentials and other account takeover techniques to masquerade as a legitimate user
• Business logic abuse that enables the use of APIs in unexpected ways

Leakage of user ID and password information from websites and SaaS platforms has become a regular occurrence. Often, these incidents result in large sets of credentials being shared widely online.

Credential stuffing is the practice of using authentication credentials leaked from previously breached websites to perform automated login attempts to other websites. This technique is based on the premise that some percentage of users use the same credentials for multiple sites.

Increasingly, this practice is being applied to APIs directly (not through the front end — be that a web or mobile application). This enables attackers to automate the attack more easily, since — after all — APIs are created for ease of consumption.

Data exfiltration is a frequent outcome of successful API attacks and abuse. In some cases, it refers to highly sensitive, nonpublic information that has been stolen by a threat actor through API attacks and abuse. However, it can also apply to less severe types of API abuse, including aggressive data scraping of publicly available data to assemble large datasets that are valuable in aggregate form.

Development practices. The following are key trends that security executives should consider when developing an API safety and security strategy.

Behavioral analytics and anomaly detection: In addition to trying to predict possible attacks and rely on signature-based detection and predefined policies (e.g., WAF) to mitigate risk, organizations are increasingly turning to AI and behavioral analytics to view API activity in a business context and detect anomalies.

Transition from on-premises to software as a service: While many first-generation API security products were deployed on-premises, software as a service (SaaS) approaches are growing in popularity due to their speed and ease of deployment and ability to harness the power of AI and machine learning at scale.

Analysis of larger time windows: API security approaches that only analyze individual API calls or short-term session activity are being supplanted by platforms that analyze API activity over days and sometimes weeks, from completing basic automated WAF policy optimization to performing behavior analytics and detecting anomalies.

DevSecOps — embracing non-security stakeholders: One of the best ways to reduce API risks is by creating greater linkage between API security strategies and tools and developers and systems involved in the creation, implementation, and configuration of APIs.

API-enabled API security: While detecting and mitigating active API attacks and instances of abuse is critical, forward-thinking organizations are finding ways to use on-demand access to API security data and insights to improve threat hunting, incident response, and API.

Signature-based API security techniques monitor for known attack characteristics and patterns, and generate security alerts and other automated responses when matches are observed. The value of signature-based detection is limited (for API security and in general), since many API attacks and abuse techniques simply don’t have a signature.

The entire premise of signature-based detection is that some telltale sign exists in a single packet or request. Not having to worry about context (Who is this user? How many endpoints did they access last month?) enables signature-matching engines to work at extremely high speeds. However, that also makes them completely miss most API attacks.

API security requires context — understanding each API request in the context of the user making it, their previous requests, and the overall request patterns of all users. API security techniques based on behavioral analytics and machine learning should therefore be used to detect abnormal use.

API detection and response is an emerging category of API security focused on deep analysis of historical data to:

• Establish the baseline for behavior of all API consumers
• Detect attacks and anomalies that indicate possible API abuse and misuse

Effective API detection and response at scale can only be delivered under a software as a service (SaaS) model due to the large datasets involved in the need for resource-intensive AI and machine learning techniques.

Advanced API threat protection is a SaaS-based approach to API security that combines behavioral analytics with threat hunting to:

• Discover all APIs in use by an organization, including shadow or zombie APIs
• Apply machine learning to overlay business context about how APIs are being used and abused
• Perform behavioral analysis and threat hunting on APIs and API activity data that is stored over extended time windows

An API security platform is a SaaS-based offering that is specially designed to:

• Create a continuously updated inventory of all APIs in use enterprise-wise (whether sanctioned or not)
• Analyze APIs and their usage with AI and machine learning techniques to discover business context and establish the baseline of expected behavior
• Detect anomalies in API usage and, when necessary, provide alert and supporting data to security information and event management (SIEM) and security orchestration, automation, and response (SOAR) workflows
• Provide on-demand access to API inventory, activity, and threat information to both security and non-security stakeholders

Organizations use many different types of API security techniques to protect their applications and sensitive data against abuse and other types of attacks. Common types of API security include:

• Scanning API code for flaws and vulnerabilities during development and testing
• Developing API threat models and implementing countermeasures like input validation
• Implementing APIs with best practices like TLS encryption, and sound and scalable authentication and authorization models
• Deploying specialized tools like web application firewalls, bot mitigation platforms, and API gateways in front of APIs
• Conducting regular vulnerability assessments to identify any misconfigurations or other implementation flaws
• Performing ongoing API discovery to ensure that all APIs in use are either protected or, if necessary, decommissioned
• Monitoring for known API attack techniques using signatures
• Monitoring for more sophisticated forms of API abuse through the use of behavioral analytics and anomaly detection
• Conducting ongoing threat hunting activities to identify and mitigate risks early and provide proactive security guidance to development and operations teams

All of these types of API security can potentially play a role in your overall security strategy, but it’s important to implement them in an integrated manner with a focus on your organization’s specific risk profile.

Now that IT and security leaders are using APIs more strategically, they may need to engage specialized API partners. The two most common types of API companies are:

• API gateway companies that provide technology to accept API calls centrally and route them to the appropriate back-end resources and microservices
• API security platform companies ensure that businesses have awareness of all active APIs, detect instances of attacks and abuse, and provide rich data about how APIs are being used

Many security teams conduct proactive threat hunting activities to identify possible threats early and respond with countermeasures. Many first-generation API security products provide limited value to threat hunting teams, since they are focused on alerting, and do not store API activity at all, which means there is no data to query and hunt through. More advanced API security companies store large and context-rich API activity datasets and make this information available both in a GUI and through APIs, so threat hunters can leverage the data.

Web application and API protection (WAAP) is a categorization that the research firm Gartner uses for its industry coverage of emerging web and API threats. It is an evolution of earlier industry coverage of the web application firewall (WAF) market in response to the growing strategic importance of API security and the move by WAF platforms to the cloud as managed SaaS.

The most common form of API documentation for RESTful APIs (which are the most common type of web API) is a collection of Swagger files based on the OpenAPI specification. Ideally, API documentation is created by developers when an API is designed or implemented. In reality, however, API documentation is frequently out of date, resulting in a mismatch between real-world API usage and documentation. To address this issue, some API security platforms can generate Swagger files from the actual API activity, highlighting the gaps between what is documented and what is actually deployed — an integral component in any API risk assessment.

Effective API security requires many detailed steps and ongoing practices. However, the following is an API checklist that security teams can use as a starting point as they move toward a more sophisticated approach to API security:

• Does your API security approach include a mechanism for continuous enterprise-wide API discovery?
• Are you leveraging the cloud/SaaS to gain access to AI and machine learning techniques and avoid unnecessary deployment complexity?
• Is your API security approach analyzing data over a long enough time horizon (ideally, 30 days or more)?
• Will your approach give your teams the business context they need to truly understand the API activity and possible risks that are being observed?
• Do you have a strategy for two-way automation between your API security platform and other related business processes like SIEM/SOAR, threat hunting, documentation, DevOps tooling, etc.?
• Are you taking steps to welcome non-security stakeholders like developers into your API security tools and processes?

The following are common categorizations and descriptions of APIs that may come up in a security context.

It is helpful for security teams to be familiar with the following terms that refer to different usage models and technology approaches for API implementations.

API security solutions refer to a set of tools and practices used to ensure the security of application programming interfaces (APIs) from malicious attacks and data breaches. APIs are widely used by businesses and organizations to enable their applications to communicate with each other, share data, and perform various functions. 

However, as the use of APIs has become more widespread, so have the security risks associated with them. APIs can be vulnerable to a range of security threats, including unauthorized access, denial-of-service attacks, and injection attacks. To mitigate these risks, businesses need to implement robust API security solutions.

API security solutions include:

• Authentication and authorization: API security solutions involve authenticating and authorizing the users who access APIs to ensure that only authorized users can access and manipulate data. Authentication methods include multi-factor authentication, OAuth, OpenID Connect, and API keys, while authorization methods include role-based access control and attribute-based access control.
• API gateway: An API gateway is a component of comprehensive API security solutions, acting as the entry point for all API requests. The gateway can perform several functions, including authentication, rate limiting, traffic management, and caching, and can help prevent attacks such as distributed denial of service (DDoS).
• Encryption: API security solutions also involve encryption, which ensures that data transmitted over APIs is secure and cannot be intercepted by attackers. Encryption techniques include SSL, TLS, and AES encryption, which can be used to encrypt API requests, responses, and data at rest.
• Rate limiting: Rate limiting is a feature of an API security solution that helps prevent denial-of-service attacks by limiting the number of requests a user can make within a specified time period. Rate limiting can be based on IP addresses, user accounts, or other parameters, and can help prevent attackers from overwhelming APIs with requests.
• Auditing and logging: API security solutions should also include auditing and logging, which can help detect and mitigate security threats by providing visibility into API activity. Auditing involves tracking API requests and responses, while logging involves recording API events and activities in a secure and tamper-proof manner.
• API testing: API security solutions also involve testing APIs to identify vulnerabilities and potential security risks. API testing can be performed manually or using automated tools, and can help ensure that APIs are secure and that they function as intended.
• API monitoring and runtime protection: API behavior must be monitored in an API security solution. Understanding normal behavior versus abnormal abuse is an essential component of protecting APIs from malicious users.
• Vulnerability management: API security solutions also involve vulnerability management, which involves identifying and addressing security vulnerabilities in APIs. Vulnerability management can involve vulnerability scanning, patching, and remediation, and can help prevent attackers from exploiting known vulnerabilities in APIs.

API security solutions are critical for ensuring the security and integrity of APIs. By implementing authentication and authorization, API gateway, encryption, rate limiting, auditing and logging, API testing, monitoring, runtime protection, and vulnerability management, businesses can ensure that their APIs are secure and protected from a range of security threats. 

As APIs become more integral to business operations, businesses must invest in robust API security solutions to protect their sensitive data and intellectual property.

Behavioral analytics is a security approach that uses machine learning and data analysis to identify anomalies and patterns in user behavior. This approach is used to detect and prevent security threats such as insider threats, account takeover, and fraud. 

Behavioral analytics is becoming increasingly important in the field of API security, as APIs are becoming more widely used and increasingly targeted by cybercriminals.

APIs are used by businesses to enable their applications to communicate with each other, share data, and perform various functions. However, as the use of APIs has become more widespread, so have the security risks associated with them. 

APIs can be vulnerable to a range of security threats, including unauthorized access, denial-of-service attacks, and injection attacks. Behavioral analytics can help detect these threats by analyzing user behavior and identifying anomalous patterns that could indicate an attack.

Behavioral analytics is a critical component of API security because APIs can be a target for cybercriminals seeking to gain unauthorized access to sensitive data or disrupt business operations. Behavioral analytics can help detect these threats by analyzing user behavior and identifying anomalous patterns that could indicate an attack.

API security solutions that incorporate behavioral analytics can help identify and prevent attacks such as:

Account takeover: Account takeover occurs when an attacker gains access to a legitimate user’s account and uses it to access sensitive data or perform malicious actions. Behavioral analytics can help detect if an account has been compromised by analyzing user behavior and identifying anomalous patterns that indicate an attacker has gained access to a user’s account.

Insider threats: Insider threats occur when a trusted user with authorized access to an API uses that access for malicious purposes. Behavioral analytics can help detect insider threats by analyzing user behavior and identifying anomalous patterns that could indicate a user is behaving suspiciously or maliciously.

Injection attacks: Injection attacks occur when an attacker injects malicious code or commands into an API request to exploit a vulnerability and gain unauthorized access to sensitive data. Behavioral analytics can help detect injection attacks by analyzing user behavior and identifying anomalous patterns that could indicate an attacker is attempting to exploit an API vulnerability.

Denial-of-service attacks: Denial-of-service (DoS) attacks occur when an attacker overwhelms an API with requests to disrupt business operations. Behavioral analytics can help detect DoS attacks by analyzing user behavior and identifying anomalous patterns that could indicate an attacker is attempting to flood an API with requests.

As APIs become more widely used and increasingly targeted by cybercriminals, businesses must invest in robust API security solutions that incorporate behavioral analytics to protect their sensitive data and intellectual property.

Managed threat hunting is a proactive security approach that involves using advanced tools and techniques to identify and mitigate potential security threats before they can cause damage. 

Managed threat hunting is a type of service offered by a few API security firms, in which a company pays a third-party provider to manage and carry out threat hunting on their behalf. This service allows companies to benefit from the expertise and resources of a specialized security team, without having to invest in their own internal threat hunting capabilities.

The managed component of managed threat hunting means that a company is paying an API security firm to perform threat hunting for them. This involves the API security firm carrying out proactive monitoring of the company’s API infrastructure, analyzing logs and other data sources, and using advanced techniques such as machine learning and behavioral analytics to identify potential security threats. 

The API security firm then works with the company to remediate any identified threats and provide recommendations for improving its security posture.

Managed threat hunting is especially important in the context of API security, as APIs can be vulnerable to a range of security threats, including injection attacks, account takeover, and denial-of-service attacks. 

Managed threat hunting can help identify and mitigate these threats before they can cause damage, allowing companies to protect their sensitive data and intellectual property.

The key components of managed threat hunting include:

• Proactive monitoring and investigations: Managed threat hunting involves proactive monitoring of a company’s APIs to identify potential security threats. This can include monitoring of all API activity data including system logs, and other data sources, or by investigation of detected alerts.
• Storage of historical API data: All API data must be stored to allow the possibility of performing investigations and threat hunting. Access to the data is a prerequisite for managed threat hunting.
• Advanced detection techniques: Managed threat hunting uses advanced techniques from technology such as machine learning and behavioral analytics to identify potential security threats. These techniques can help identify threats that may not be detectable using traditional signature-based approaches.
• Threat hunting team: Managed threat hunting involves a dedicated team of security professionals who are trained and experienced in identifying and mitigating potential security threats. The API security firm providing the service will typically have a team of experts with specialized knowledge of API security threats.
• Remediation and recommendations: Managed threat hunting involves working with the company to remediate any identified threats and provide recommendations for improving their security posture. This may involve patching vulnerabilities, improving access controls, or implementing other security controls into other tools like WAF, CDN, or other proxies.

In the context of API security, managed threat hunting can help identify and mitigate a range of threats, including injection attacks, account takeover, and denial-of-service attacks. 

By investing in managed threat hunting, companies can ensure that their APIs are secure and protected from a range of security threats.