Are you ready for API security?

All applications use APIs (calls to the kernel, software development kits, cryptographic libraries, and SOAP, to name a few examples)—they’re nothing new. What vendors call “API security” today refers to a subset of those APIs—those exposed over a network. By their very nature, these network-exposed APIs enable the free flow of information and interaction between software components. Attackers have new opportunities to poke and prod these components of your systems with the exposure of endpoints to public, cloud, and private networks. We have seen high-profile breaches at several well-known companies (USPS, T-Mobile, and Salesforce to name a few) stemming from the exposure or use of insecure API endpoints. This raises the question, How do you know whether your software security initiative addresses the controls you need to ensure the APIs you use and produce are secure? To answer that question, you first need to define “API security.”

What is ‘API security’ exactly?

API security is the protection of network-exposed APIs that your organization both produces and consumes. Of course, this means the use of common security controls germane to APIs: rate limiting and the authentication and authorization of users, services, and requests. It also means understanding data provenance and, when looking at composed systems, where exactly to seek context during design or review discussions. For leaders it means that application security programs capture and apply activities to software exposing or using APIs at the right time. More than just buying some new tools, robust API security stems from a culture of security, with activities across the software security initiative.

Addressing API security

Popular software development trends like microservices architectures have driven the unit of software relevant to an SSI from an “application” (or monolith) to many subcomponents that expose APIs, with their own life cycles and contracts to uphold—as well as security controls that must exist. Software security leaders can find opportunities for improvement in the following areas:

Designing APIs

APIs are used between front-end clients (thick clients, browsers) and back-end systems, as well as between back-end components. Muddling further, a single API endpoint may end up serving a mix of both front-end and back-end requests. When individual API endpoints are exposed to a variety of known and unknown callers (consumed, composed, or wrapped upstream by gateways or load balancers), it is difficult to determine what security controls an individual API endpoint must enforce. One decision that application security leaders can make is to push for APIs that explicitly document the assumed security responsibilities for both provider and consumer.

Architects are also faced with identifying cross-cutting problems for APIs. Security leaders should pay attention to those security efforts, like unifying access control, as well as those close to the business logic, like unifying customer identity.

Inventory

Leaders need to generate visibility into the organization’s API footprint; measure efforts to cover that footprint with process and tools; track, record, and prioritize ongoing security activities; and provide rich context for various types of security analysis. When we talk to program owners about API security, we often see that existing inventory solutions just do not generate this insight. Program owners can carefully consider whether existing inventory solutions can be adapted, or if new solutions must be adopted.

Filling up your inventory with accurate information is another matter entirely. Organizations can source some information from development groups, but they should invest in discovering process escapes. Sources of this information include sensors deployed on client and service codebases (or binaries or live instances), network inspection, OSINT techniques, and pure black box discovery. At the end of the day, you should be able to plumb the results of discovery sensors into your inventory and act on those APIs you know nothing about.