For many small and medium-size organizations, the application programing interface (API) has become necessary for driving business growth. Between the pandemic and the current economic headwinds, organizations are facing constricted budgets. Just “good enough” has become a mentality that IT professionals and security staff are facing when considering coverage and cost savings. Issues such as financial constraints, staff attrition and skills gaps, and the desire to do more with less can impact the business practices that ensure data-driven operations.

APIs help automate portions of the business, integrate with cheaper solutions that organizations are deploying in cloud services, offer real-time internal and client-facing communication, and provide the ability to extract information for reporting functions. Although these are good options, it is important to consider whether the security of these solutions is “good enough.”

API Security

Organizations should review several items when considering the deployment of APIs within their environment. Network and web application vulnerability scanners provide an initial review of patching and misconfiguration or low-hanging fruit items that malicious attackers can exploit. Although these scanners work well, they have severe limitations.

API calls typically crafted by the user will often give an automated scanner nothing to crawl. Links are seldom contained within responses. Spidering is generally ineffective based on these issues. Unfortunately, developers often overlook API security in favor of functionality. If a response is generated as part of the API communication, then it may not matter if extraneous details such as personal information have been provided.

Web application penetration testing focuses on automated scanning and manual testing for errors. Exploitation may result in violation of data integrity, application availability, or data confidentiality. These issues exist within the API, but the penetration test may not have addressed them. A unique API methodology is needed, typically because a penetration tester may not see API response issues within the web user interface during testing. Often, developer documentation, Swagger, or Postman files are necessary to provide thorough testing. These are items you typically do not see in a web application penetration test.

What to Do

There is a four-phased approach in addressing API security:

This first blog post of the API Security Series addresses what may be the most important part of an API Security Program, which is Discovery.

Diving Into Discovery

An organization should first identify what APIs are present and where they are hosted. Discovery must be considered on both the perimeter and internal portion of the organization. One of the major issues with discovery is the current understanding of the API environment. If you have knowledge of the API, you can perform normal reconnaissance from utilities such as Nmap to enumerate ports that are open, services that are running, and http responses. This general knowledge will point you toward the use of a web browser, which should be proxied so you can view the requests from the browser. However, you still may not determine if an API call is being completed in the background while performing this search.

You will also need to perform active reconnaissance against endpoints with utilities such as wfuzz, kiterunner, and any directory brute-force tool. Again, if you understand the API environment and the available targets, it can be easy to scan for popular API layouts.

Other providers such as Microsoft, Oracle, Hewlett Packard, and IBM all have integrated solutions for addressing API needs and may help address the discovery of APIs. Products like Amazon API Gateway and Azure API Management are ideal solutions to research. Providers also have built-in solutions, such as the Cloudflare API Gateway.

Digging further into discovery, vendors like NoName Security, MuleSoft, Apiiro and Cequence offer additional support to identify all public-facing API domains, help understand the attack surface, review both the external and internal organization, perform API monitoring, and protect APIs from design to development.

Using some or all of the above strategies will put you on the right course to securing APIs within your environment. In our next blog post, we will dive into the inventory phase and determine how proper API inventory can reduce redundant development costs by identifying duplicate API functionality.