Secure APIs in an API Gateway
In June 2021, almost 92% of LinkedIn users’ data was leaked by public APIs that lacked security controls. The exposed data, which was sold to the public on the black market, contained 700 million user names, personal data, email addresses, phone numbers, and other specifics. Although LinkedIn views this event as a crawl of public data rather than illicit access, it nonetheless highlights the significance of API security measures.
As the external interface for applications to provide services, APIs are constantly exposed to external traffic, encountering hostile attackers that employ denial of service, injection, and known vulnerabilities to attack. For instance, attackers leveraged the log4j 2 defects in December 2020 to perform unconfigured attacks against APIs. Therefore, it is necessary to strengthen the API's capability to keep these malicious attackers out. However, before we adopt measures to secure an API, let's first understand what an API is.
What is API?
Traditional API（Application Programming Interface) stands for the software's static or dynamic link libraries to invoke its functions. Developers can reuse the functions provided by existing software based on calls to its APIs, such as TCP/IP, provided by operating systems.
With the evolvement of software systems and networks, the term "API" now refers to system interfaces accessed through a network. Clients call these interfaces using protocols like HTTP to perform client functions, such as querying the Weather API for weather information.
In its original sense, API refers to a channel provided by the software system for other services, which defines the specification of interoperation among various subsystems. The authentication service, for instance, provides interfaces for user login, registration, and the acquisition of user information. Other services can use these call interfaces to complete the function of user authentication. Similarly, through the API, subsystems can cooperate to fulfill the task of the entire application.
What is API Security?
After the overview of API, we will introduce API security now. API security involves three main perspectives:
Information Security (InfoSec): From the information perspective, ensure that the information has been under protection during its generation, transmission, storage, and destruction of the entire life cycle.
Network Security (NetSec): From the network perspective, ensure that the transmitted data over the network isn't eavesdropped on or tampered with and that no unauthorized individuals access the network.
Application Security (AppSec): From the application system perspective, ensure that the developed applications can prevent malicious attacks.
Common API Security Attacks
OWASP, the opened Web application security project, has published a list of 10 common API security issues OWASP API Security Project | OWASP Foundation.
It contains the following issues:
Broken Object Level Authorization: Users access data objects to which they do not have access.
Broken User Authentication: Authentication service implementation error allows users to bypass the authentication mechanism to access the API illegally.
Excessive Data Exposure: Allow the users to get excessive sensitive data, which is supposed to be prohibited.
Lack of Resources & Rate Limiting: Lack of restrictions on the number of resources needed to fulfill customer demands, as well as realistic request volumes.
Broken Function Level Authorization: The users access a feature API to which they do not have access. Mass Assignment: Users unintentionally change the data they are not authorized to edit through an incorrectly developed interface.
Security Misconfiguration: Improperly configured security measures for the API.
Injection: Untrusted data input sets off SQL, command injection, unforeseen command execution, or data access.
Improper Assets Management: Manage the API resources improperly, such as releasing the APIs for test environments or the earlier incorrect offline API versions.
Insufficient Logging & Monitoring: It is challenging to identify security abnormalities using audit methods due to the absence of logging and monitoring tools for API access.
After noticing the common issues related to API security, what should be implemented to protect API?
How to protect your API?
In terms of protecting API, it is also possible to take measures from three perspectives:
InfoSec: We can build a confidentiality system for information in compliance with legal policy and security requirements to avoid disclosing personal information.
NetSec: Encryption and verification of the data transmission are necessary.
AppSec: We need to harden the security of the application.
Here are some additional practices for API security.
Constant encryption: We can prevent data eavesdropping and data tampering circumstances caused by unmanaged networks through a full-flow TLS setup. In addition, it is also necessary to enable mTLS to verify the client side's correctness to prevent unauthorized access.
Use tokens with caution: We need to be cautious about employing JWTs since it allows the client to decode them, which could expose confidential information if improperly utilized. Additionally, we will need help when revoking a specific login session since applying a revocation procedure is complicated due to its limitations.
Smaller Permission Granularity: Assign minimal permissions to API and data access to circumvent the possibility of unauthorized access.
Input validation: Never trust the client's input values. You must validate the client's input values to ensure they meet security requirements.
Rate limiting: Limit the pace of API access. This measure prevents denial-of-access attacks, which happen when a system is overloaded with requests that cannot handle them all at once.
Logging and monitoring: Designing an appropriate logging and monitoring mechanism for the system enables us to identify security events and take appropriate action quickly. We can also go back in time after an information security event to identify the affected systems and data and determine the extent of any potential data leaks.
The measures mentioned above require us to make specific changes to the application system by processing individual components, which are not only very expensive but also prone to further issues.
How can we put security measures into place without jeopardizing the application services?
API gateways offer a new path outside of system transformation, which significantly reduces the cost of transformation and provides centralized and unified ingress traffic management. Rich security features are also offered by API gateways, which enable us to prohibit and record unauthorized visits.
By using Apache APISIX as an example, the following section will describe several API gateway application scenarios for securing APIs.
You can not only enable TLS for the API to offer HTTPS access but also activate mTLS to verify the client's identity. Naturally, it is also possible for you to activate TLS/mTLS for upstream services to guarantee the security of traffic while it is traveling through the internal network. You can consult the mTLS manual to activate the necessary functionality.
All connections can be encrypted, but this does not guarantee the security of the API. As a result, in real-world business settings, we must include components linked to authentication. To address this issue, APISIX offers a variety of plugins that are connected to authentication that may be easily interfaced with external authentication services or directly through the gateway. These plug-ins range in complexity from the simpler LDAP, OpenID Connect, and Open Policy Agent to the more complicated ones like Basic Auth, Key Auth, JWT Auth, and Forward Auth.
Lack of Resources and Rate Limiting are two frequent assaults. For these situations, gateways often include plugins related to rate-limiting; so does Apache APISIX. It offers three plugins: limit-count, limit-req, and limit-conn, which give the API request speed, request measurement, and connection limiting features. They can help to effectively control the API access pressure and prevent the system from becoming overloaded with unmanageable amounts of requests.
APISIX offers CORS and CSRF plug-ins to provide cross-domain and cross-site request forgery protection for the API, further enhancing its capacity to safeguard its security. Additionally, its restriction plug-ins enable the ability to block IP, UA, Referer, and URI, which may counteract the majority of API assaults.
APISIX provides the request-validation plugin, which allows API providers to validate user input via jsonschema. The structured data and validation rule description language can be well used for data validation.
The methods listed above are all ways to safeguard the API. However, no system is completely secure. Once a system is attacked, we must act fast to determine the cause of the attack and prevent further damage from the attack. As a result, APISIX also offers a wide range of logging plugins, which can send logs to various destinations, including Kafka, Clickhouse, and logging-as-a-service solutions offered by cloud providers like Google Cloud, Splunk, etc.
Furthermore, APISIX offers link-tracking functionality with docking to Skywalking, OpenTelemetry, and other tracing programs.
In addition, APISIX provides the Prometheus plugin, which can compute and export metrics linked to API requests to the Prometheus monitoring service to assist in identifying performance issues and averting systemic service interruptions.
We can identify potential security incidents on time by making the system sufficiently observable.
Last but not least, APISIX also offers a serverless plugin to address 0-day vulnerabilities, allowing users to utilize Lua code to perform some logic when the request comes. We may take advantage of this functionality to temporarily block some 0-day vulnerabilities as they arise.
API security is essential for service providers, so developers must make an effort to keep it up to date. In order to demonstrate how API gateways may be used in different application settings, this article uses Apache APISIX as an example, which is a novel strategy that differs from system modification that aids developers in lowering the cost of security concerns.