API security MATTERS

The purpose of an API is to facilitate communication and interfacing with an application so that external parties can make requests and perform actions in a fast and more efficient method than manually navigating to that web application and performing data entry for each request. One of the most popular types of APIs, especially for web applications, is the representation state transfer, or RESTful API method, which uses HTTP web requests to facilitate communication and interfacing with a web application.

For example, when customers use a mobile application, that application communicates using REST APIs to perform actions on a web application. So whenever a user creates a request, such as requesting to purchase a service, that request is sent as an HTTP method, whether it be HTTP GET to retrieve information, HTTP POST to submit new information, or HTTP PATCH to update information; that web communication is handled by a RESTful API.

There’s a security concern with receiving such requests

from an untrusted source outside of the organization, and several risks should be taken into account when using APIs.

The Open Web Application Security Project, OWASP,

is an organization dedicated to the security of web applications,

and they compiled a list of the common API risks facing application programming interfaces:

1. Broken Object-Level Authorization — What this means is that an attacker can make unauthorized changes at the object level of the application. So if your web application’s API performs actions using an object identifier, it is important to make sure that the user making this request is properly authorized to perform that action.
2. Broken User Authentication — this means that you have an issue with user authentication that can lead to unauthorized access and changes via your API.
3. Excessive Data Exposure — involves your API disclosing too much information, which can be leveraged against the web application in an attack.
4. Lack of Resources and Rate Limiting — a special concern to the availability of your web application since your APIs can become overwhelmed with requests and possibly crash your web application.
5. Broken Function-Level Authorization — concerns functional level authorization. So an attacker can exploit the API to perform functions such as creating web application accounts when that functionality should only be authorized to administrator users.
6. Number six, Mass Assignment — And this happens when an object’s properties can be manipulated by an attacker for their benefit. For example, the attacker can manipulate the API request to modify properties like extending their free trial to your web application or adding credits to their account.
7. Security Misconfiguration — lack of application hardening that leaves the web application vulnerable.
8. Injection — These attacks include cross-site scripting and SQL injection.
9. Improper Assets Management — A lack of tracking APIs in understanding what APIs are still out there, which leads to a lack of visibility in which an attacker can leverage an older, weak API, to perform some of these other attacks that we discussed.
10. Insufficient Logging and Monitoring — Lack of visibility and logging of our APIs. If we’re not receiving information about the APIs, you can’t secure them or even understand if an attack is taking place.

What should you do?

To deal with these risks, the 3 major Cloud service providers offer configuration of API gateways to configure and manage open APIs. Both AWS and GCP use the term API Gateway, whereas Microsoft’s Azure uses the term API Management for their API Gateway service. All 3 major CSPs have similar controls and configurations for their API Gateways. let’s review some of the security defenses we can use as an API gateway to protect our APIs. One of the critical things to do is encrypt traffic, we can utilize transport layer security to encrypt our data in transit. Rate Limiting, as we discussed with OWASP API security, is critical to the availability of your web application. With API Gateway, we can throttle API requests and limit the rate at that requests are sent to our APIs. Logging is critical for visibility,

understanding the security posture of your APIs, and activity taking place on your APIs. So leveraging CloudWatch, Azure Monitor, or GCP Cloud logging is necessary for tracking malicious activity and security concerns around our API. That way we will have visibility into who and when has made configuration changes to our APIs. IAM policies should be implemented for access control to our API resources keeping with the principle of least privilege, not everybody needs access to make configuration changes to our APIs, so we need to limit that and lock it down. Authentication and authorization are absolute must-dos for API security. We need to know who is accessing our API, and more importantly if they have the authorization to make certain requests. So looking back at the OWASP API security list, numbers 1 and 5 both dealt with broken authorization. So the best way to deal with this is to ensure that proper AuthN and AuthZ are implemented on your API and you can leverage OAuth 2.0, OpenID Connect, or the various Identity as a Service offeringfrom the various cloud service providers. Last, we must enable policies related to how our APIs will respond to requests as well as securely storing and rotating our API keys so that they are not hard coded in a repository. We can do this by leveraging the various critical management services, like Key Vault on Azure, to do this.