What is API Security

What is API security?

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 from 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 (sensitivity x risk) 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 bad 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.

API Security 101

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 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 the crown jewels of an organization's data.

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

What is a web API?

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 by means of an HTTP-based web server.

Meaning, a web API is what most people think of when they hear the word “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 the enterprise digital transformation and API security.

The 4 common types of web APIs

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

• RESTful APIs - dating back to Roy Fielding’s doctoral thesis back 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. To learn more read our blog about REST API Security Best Practices.
• SOAP APIs - SOAP uses the verbose eXtended 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

What are the differences between B2C APIs and B2B APIs?

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 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). Newer API security solutions like Neosec are filling the void and addressing this issue.

What is the difference between APIs and endpoints?

People often use the word “API” when what they are really 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).

What is a north-south API?

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.

What is an east-west API?

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

What are the differences between private APIs and public 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 they could be used by engineers outside the company.

It’s important to note that private APIs that can be accessed over the internet, are not really 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 really private, simply undocumented. Hackers attack such APIs on a daily basis, by intercepting the traffic, and by reverse engineering mobile apps to see which APIs they interact with.

How big is the API security problem?

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, Inc., “By 2022, API abuses will move from an infrequent to the most-frequent attack vector, resulting in data breaches for enterprise web applications.”

How is API security different from application security?

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.

Greater Scale
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 of different nature – for partners, IoT and business automation.

Flexibility Leading to Complexity
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.

What is API-to-API security?

An increasing number of organizations use APIs to make business processes and data available bi-directionally with customers and partners. Many understand that business to consumer, sometimes known as B2C, APIs power data in the website or mobile apps. But 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.

What Are Web API Best Practices?

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

1. Find ways to integrate API security standards and practices with your organization’s software development lifecycle
2. Incorporate API documentation and automated security testing into your continuous integration / continuous delivery (CI/CD) pipelines
3. Ensure that appropriate and effective authentication and authorization controls are applied to your APIs
4. Implement rate limiting measures to help prevent APIs from being abused or overwhelmed
5. 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
6. Make API security testing an integral part of your broader application testing processes
7. Perform continuous discovery of APIs
8. Implement a systematic approach for identifying and remediating common API vulnerabilities, including the OWASP API Top 10
9. Use signature-based threat detection and prevention as a baseline level of protection against known API attacks.
10. Augment signature-based detection with AI and behavioral analytics to make API threat detection more scalable, accurate, business-relevant, and resilient against novel threats
11. Ensure that API security monitoring and analysis extends over multiple weeks and API sessions
12. 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.

What is an API vulnerability?

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.

Are all API vulnerabilities tracked on the OWASP API Top 10?

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.

For example, “security misconfiguration” can range from not performing proper patch management to misconfiguring your CORS header. Which carries more risk to your organization? It depends on the APIs affected, their business function and the data they carry.

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).

How can APIs be abused?

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 for these types of vulnerabilities range from the Apache Struts vulns (CVE-2017-9791, CVE-2018-11776 and friends) to Log4j vulns (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 bad 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 access (IDOR), as well as broken function-level authorization (BFLA).
• 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 data sets available through public APIs, bad actors may aggressively query these resources to perform wholesale capture of large, valuable data sets.
• Business denial of service (DoS): By asking the backend 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).

What is a zombie API?

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 sunset.

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 endpoints.

How can I find the various types of shadow 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 distribution networks (CDNs)
• API gateways
• Web applications 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.

How do you protect business-to-business APIs and internal APIs?

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.” And 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 which 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 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.

And 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 hard.

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 (e.g., invoice, payment, order, etc.) make it possible to see anomalies that would otherwise go undetected.

Do API gateways have built-in security?

Many organizations taking a strategic approach to APIs use API gateways. Common 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

What are the most common API misconfiguration errors?

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:

Broken or no authentication
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 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).

Broken authorization
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 an API consumer is eligible to access the data they are trying to access prior to making it available to them. This can be done at the object or resource level (for example, I can access my 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).

Security misconfiguration
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.

Lack of resources and rate limiting
When APIs are implemented without any limits on the number of calls that API consumers can make, bad actors can overwhelm system resources, leading to service degradation, 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, and credential stuffing and credential validation attacks are simply bound to happen.

What are API attacks?

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 use of APIs in unexpected ways

What is credential stuffing for APIs?

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.

What is data exfiltration through APIs?

Data exfiltration is a frequent outcome of successful API attacks and abuse. In some cases, it refers to highly sensitive, non-public information that has been stolen by a bad 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 data sets that are valuable in aggregate form.

What are the latest trends in API security?

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

1. Behavioral analytics and anomaly detection: Rather than trying to predict possible attacks and relying on signature-based detection and pre-defined policies (e.g., WAF) to mitigate risk, organizations are increasingly turning to AI and behavioral analytics to view API activity in business context and detect anomalies.
2. 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) based 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.
3. 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.
4. 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.
5. 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 development practices.

What is signature-based API security?

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, as well as abuse and misuse 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 she 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, her previous requests, and the overall request patterns of all users. API security techniques based on behavioral analytics and machine learning (ML) should therefore be used to detect abnormal use.

What is API detection and response?

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

• Baseline the 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 data sets involved in the need for resource-intensive AI and machine learning techniques.

What is advanced API threat protection?

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.

What is an API security platform?

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 baseline expected behavior
• Detect anomalies in API usage and, when necessary, provide alert and supporting data to security incident and event management (SIEM) and security orchestration and response (SOAR) workflows
• Provide on-demand access to API inventory, activity, and threat information to both security and non-security stakeholders.

What types of API security are available?

Organizations use many different types of API security techniques to protect their applications and sensitive data. 

There are many different types of API security that protect APIs 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 applications 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.

What is an API company?

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 backend resources and microservices.
• API security platform companies that 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.

What is threat hunting in APIs?

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 data sets and make this information available both in a GUI and through APIs, so threat hunters can leverage the data.

What is WAAP?

Web application and API protection (WAAP) is a categorization that the research firm Gartner, inc. 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.

What is an API documentation example?

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, including Neosec, 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.