What is API Security?

Overview

Application Programming Interfaces, or APIs, play a critical role in allowing software applications to communicate with each other. But they can also become vectors for attack. When an API lacks security protections such as effective access controls or input validation, threat actors may misuse the API as a way of exfiltrating sensitive data from an application, manipulating application behavior or disrupting critical services.

API security mitigates these risks. By following API security principles during all stages of the API lifecycle – such as building security controls into APIs during the design stage, carefully assessing APIs for security risks during testing, and monitoring for API attacks in production – organizations can minimize the chances that APIs will become the weakest link in their security posture.

What is API security?

API security is the practice of minimizing security risks associated with Application Programming Interfaces, or APIs.

To understand the definition of API security fully, it’s helpful to understand how APIs operate. Again, an API is a mechanism that allows two or more applications to exchange data. APIs work by defining a set of rules that define how one application should format data and send it to another application. They also define how the receiving application can send a response back to the original app.

While APIs serve a legitimate and crucial purpose in enabling applications to communicate with one another easily, they can also become an attack vector. Threat actors could use an API to send a malicious request to an application, as one example. As another, they could leverage an API that lacks authentication controls to request data that should not be publicly available. Or, they could abuse an API by flooding it with requests as a means of overwhelming the application or server that hosts the API – an example of a Denial-of-Service (DoS) attack.

API security defends against these risks. By understanding security threats against APIs and taking steps to mitigate them, developers can design, implement, and deploy APIs that are resistant to abuse and attack.

Securing APIs across the API lifecycle

To protect APIs, developers must integrate security into all key stages of the API lifecycle, including:

• Design: When designing how an API will function, developers should factor in considerations such as ensuring that it includes appropriate access controls and rate-limiting capabilities.
• Implementation: When writing the code to implement an API, it’s important to avoid mistakes that could cause some of the intended security capabilities not to work properly.
• Testing: Developers typically test APIs prior to deploying them for real-world use. Testing should evaluate whether APIs are resistant to security attacks as well as assess performance.
• Consumption: When APIs are being consumed, meaning they are available for use by production applications, teams should monitor for and respond to signs of attack, such as a large volume of unusual API requests that originate from an untrusted source.

Top API security threats

The leading reference on API security threats is OWASP’s list of Top 10 API Security Risks. Key threats identities by OWASP include:

• Broken object level authorization: This risk arises when an API fails to validate users or request prior to granting access to an object (meaning a resource, such as a type of data, that the API can serve). By exploiting this flaw, attackers can gain access to data or other objects that should not be available to them.
• Broken authentication: APIs that don’t properly authenticate requests (or that lack any kind of authentication mechanism at all) are subject to broken authentication. This allows attackers to issue requests that should not be available to them by acting as if they are legitimate users of the API.
• Server-side request forgery: SSRF happens when an API responds to a request without checking whether the requested destination is legitimate. Attackers can abuse this flaw to send requests to destinations of their choosing, leading to the exposure of sensitive data.
• Unrestricted access: APIs without access restrictions can potentially be abused to disrupt application or service availability. For instance, if there is no limit on the number of API requests that an application can attempt to process per minute, attackers could issue so many requests that they cause the application to crash.
• Broken function level authorization: This type of API vulnerability affects APIs that don’t properly validate requests for API functionality. For example, an API might allow a non-authenticated user to request that an application perform an action that developers intended to make available only to authenticated users.

Other types of common API security risks not detailed on OWASP’s list include:

• Injection: An API injection attack happens when APIs accept input without properly validating it, allowing attackers to insert malicious requests to an application.
• Excess data: APIs should expose only the minimum data necessary to fulfill a request. Those that provide more data are subject to excess data risks, which could result in the leakage of sensitive information.
• “Shadow” APIs: A shadow API is one that is exposed but not properly secured, managed or monitored. Shadow APIs often emerge because developers in one part of the organization implement an API without informing others or following enterprise rules about API design and security. They are a risk because a lack of security standards and monitoring may make them easier to attack.

API protection best practices

Because the security and usage context surrounding APIs can vary, there is no single set of steps that developers can follow to maximize the security of APIs. In addition, differing API use cases mean that security standards can vary. For example, when designing a public API, it may not make sense to require authentication, since the purpose of most public APIs is to allow an application to receive data from any other application or service. However, a private API should require authentication in most cases because private APIs enable connections only to trusted applications and services.

That said, there are general security best practices and API protections that can help mitigate security threats against APIs of virtually all types, across all use cases:

• Always encrypt data: The data exchanged via APIs should be encrypted. Encryption minimizes the risk of third parties being able to intercept and read sensitive data during an API transaction.
• Require strong authentication: For APIs that don’t need to support non-authenticated requests, developers should implement strong authentication via methods like OAuth or JWT.
• Test APIs for security flaws: To detect API security threats that developers may have missed, it’s a best practice to run tests that simulate malicious activity against APIs and evaluate how they respond.
• Limit API requests: To mitigate the risk of API abuse, organizations can restrict the number of requests that an API will accept. Restrictions can be implemented within an API itself, or enforced using a tool like an API gateway (an intermediary that intercepts API requests between applications and can block malicious requests).
• Monitor APIs: Monitoring APIs during runtime (meaning the period when APIs are available for real-world use) can reveal attempted attacks or abuse – such as a string of unusual requests, which could reflect efforts by threat actors to discover and exploit security flaws in an API’s authentication or authorization mechanisms.

API security vs. general application security

API security shares some concepts and practices with application security. For example, it’s important in both contexts to implement strong authentication controls and to perform adequate security testing before releasing products into production.

However, APIs are not the same as applications, and API security differs from application security in key respects:

• Types of attacks: Applications are subject to a wider range of potential types of attacks – ranging from code injection risks, to supply chain attacks, to vulnerability exploits and beyond. In contrast, most attacks against APIs abuse weak or missing authentication, authorization or rate-limiting controls.
• Code-based exploits: In application security, flaws in source code (such as lack of input validation) are a common source of security risks. APIs also depend on code, but the code is less extensive and is rarely the cause of security issues. Instead, API security flaws tend to result from design mistakes, such as failing to require authentication.
• Security tools: The tools available for securing applications are different from those used to secure APIs. For instance, vulnerability scanners that check for software components linked to CVEs are a key application security tool, but they would not help you protect APIs. Instead, to scan an API, you would typically use a type of scanner that simulates malicious requests (DAST scanners use a similar method to check for application security risks, but they are only one type of application security scanner).

JFrog and API security

The JFrog Software Supply Chain Platform delivers a variety of protections – such as application scanning, secret scanning, supply chain security, and secure artifact management – to help keep apps secure and mitigate risks no matter where they arise.