API Security Best Practices

Over the last couple of years, I’ve come to realize that Application Programming Interfaces (APIs) are often an afterthought in an organization’s security program.  Many organizations are not even aware of the number of external APIs supporting their information systems, nor do they have thorough insight into the activities of internally developed APIs.

An API-Driven Increase in Attack Surface

To effectively facedown modern threats, organizations must check and continuously monitor internal and external APIs. In its report, “API Security: What You Need to Do to Protect Your APIs,” Gartner estimates that “by 2021, 90% of web-enabled applications will have more surface area for attack in the form of exposed APIs rather than the UI, up from 40% in 2019.” Gartner also estimates that by 2022, APIs will provide the most useful attack vector for bad actors.

A simple analogy may help understand the API security challenge.  APIs can be compared to windows and doors of a home. Each should have a lock to protect the house from unauthorized access. The more windows and doors, the more challenging it is to manage the security of the house, and the greater the attack surface.

Imagine living in a large mansion, with maybe more than a dozen doors and even triple that many windows. The task to check their security every night before bedtime would be daunting. But if even one is left vulnerable, think of the damage that can be caused to the data (people) inside, completely unaware of the breach until it’s too late to prevent.

Missing the APIs Trees in the Security Forest

APIs are integrated into just about every modern information system. However, they are an easily overlooked technology due to their inherent ‘unseen’ state.  It is tempting to employ the ‘set it and forget it’ method of deploying an information system component that leverages APIs. However, although easily configured, they are just as easy to configure incorrectly. This introduces vulnerabilities into an information system that may otherwise be avoidable.

This ‘out of sight, out of mind’ property also makes them an easily overlooked technology from a security advisory perspective. Security advisors brought into discussions on how to best architect a system based on a particular security framework and government requirements may quickly grasp the big picture of an information system. However, the granular details, such as APIs, their types, use cases, security protection mechanisms, and connectivity, both internally and externally, may escape scrutiny.

API Overview

Without going too deep into the potential exploitable characteristics of APIs and their architecture, this article provides the basic concepts of API security from an advisory perspective.

Currently, there are three primary types of APIs:

  • Private API – internally developed for use within a specific information system, private APIs allow for communication between services and components internal to an information system. These APIs usually reside behind a border firewall, VPN, or another boundary protection component.
  • Public API – published and usually shared freely on the internet, public APIs provide application and data access to consumers.
  • Partner API – not necessarily private or public, partner APIs are not strictly for internal communication, nor are they shared freely on the internet to any consumer of a service. Instead, they provide communication between two or more organizations in a controlled manner.

In addition to the three API types, APIs also come in different architectural flavors, SOAP and RESTful. SOAP is an older API type that relies on XML, while JSON-based RESTful APIs are a more recent addition to the API family.

Example API Attack Types

Just as application code, Infrastructure-as-Code, and scripts are managed through a secure code development and deployment pipeline approach, APIs should be managed similarly.

When advising a client on their information system and development processes, APIs should be an integral part of the conversation. An advisor should spend time discussing the organization’s API development, deployment, and secure management processes. That advisor should also have at least a basic understanding of the different attacks that are possible against APIs that are left insecure and/or unmanaged.

The most common attacks are as follows:

  • Denial of Wallet – This attack lets bad actors trick the information system into thinking that a customer has an increase in users, thus spinning up additional resources to scale with the need and increasing infrastructure costs. Although organizations may pass this cost onto their customers, some entities will be affected by the increase in resources and additional costs. This may be prevented through closely monitoring the use of API authentication and authorization processes.
  • Denial of Service – This involves a disruption of service by overwhelming the information system with fake or illegitimate requests. If successful, these attacks may crash the web application or other service to prevent the availability of the service or data to legitimate consumers.
  • API Authentication(less) – Without strong authentication a bad actor may have unrestricted access to the API. This may give them access to data that was only intended for a specific targeted group of users or service. OAuth and OpenID are useful security practices along with TLS to provide robust authentication mechanisms for API usage.
  • Injection – These attacks allow the input of invalid data or data that does not meet the intended structure or parameters of the input field established by the organization. This can trick the application into revealing, destroying or modifying data.
  • Weak Encryption – Encryption is necessary to protect the confidentiality and integrity of the data traversing an API. Configuring an API to use weak encryption exposes its data to potential tapping, theft, or even unauthorized modification.

API Security Best Practices

Securing APIs involves controlling access, monitoring use, securing transactions, and analyzing opportunities for improvement.

Know what assets are publicly exposed to the internet and use APIs to pass traffic from the information system to a user or service outside of the information system. Take inventory of all public-facing assets and public-facing APIs. Document all public-facing APIs, their architecture, API form (Public, Partner, Private), API type (REST, SOAP, Legacy), what data is being transferred (the following FedRAMP RAR template Table 3.4 is a great starting point for documenting APIs).

Here are some key concepts in ensuring API Security:

  • Authentication – Ensure that only authorized users/services have access to the service or data served by the API.
  • Authorization – APIs should be developed with intelligence to determine the level of authorization a user or service has.
  • Encryption – Use TLS 1.2 or greater to encrypt connections.
  • Availability – Establish rate-limits to prevent DDoS.
  • Injection Prevention: Configure the API to accept only defined parameters and data structures as intended by the organization.
  • Auditing – Audit activities, including but not limited to the creation and deletion of users, permissions changes, password changes, user logins, and session timeouts and terminations. Additionally, include auditing of APIs as part of continuous monitoring.
  • Removal – sometimes APIs are forgotten but remain active. When “shadow APIs,” or APIs are discovered, those APIs must be removed. Shadow APIs often degrade and negatively impact the confidentiality and integrity of the information system, by simply being left unchecked.
  • Testing – Scan APIs during the development process, incorporate manual/peer review if possible, and continuously scan APIs in production via continuous web application and / or penetration testing.
  • Pipeline – The use of an API pipeline as an API development best practice is key in the creation, testing, and deployment of the API(s) to the production environment. Considering that APIs are essentially code-based applications, employing pipeline mechanisms as with other application code is important in the security development and control of the API and its impact on the information system.
  • API Gateway – Funneling APIs from external sources through a singular point of access at the boundary of an information system is an established best practice. This mechanism limits multiple API access points and provides a means for better controlling and monitoring of APIs before they reach the intended information system component.

Another key concept of API security, one that may not be technical in nature but is still critical, is ‘Reporting’. Although the means of reporting may use automated tooling, the idea behind reporting is to simply inform appropriate personnel of detected issues as quickly as possible. This provides a live consensus on the status of the API architecture within the information system and supports on-the-spot remediation, as opposed to a vulnerability being detected upon weekly review of logging data.

Towards a Modern API Security Approach

The speed of modern development/operations (DevOps) and Continuous Integration / Continuous Deployment (CI/CD) processes complicates the API security game. APIs must be thoughtfully designed and managed via a lifecycle process. 38North Security can help you wrangle APIs and harden your overall security and compliance posture.