Protecting Business Means Protecting APIs

APIs create value through their ability to abstract at the application layer. For example, the use of an API to abstract access to internal systems and data provides a way to simplify and automate access to legacy IT systems. APIs are also the means by which integration into ecosystems—and with partners—is achieved. APIs are also the primary means of automation and orchestration today, which make them one of the keystone technologies of a successful digital transformation journey. Thus, APIs have become strategic to businesses as a source of innovation, efficient execution, and monetization.

Monetization 

In a digital economy, everything that can generate revenue will eventually be monetized. That's especially true of APIs, and research indicates that the API economy is a strong one.

• More than one in ten (11%) of businesses generate more than half their revenue from APIs and API-related implementations. (Business Value of APIs) 
• A staggering 59% of businesses generate between 26% and 50% of their organization’s revenue from APIs. (Business Value of APIs)

Integration

APIs have supplanted ESB and web-based portals as the primary means of business-to-business integration. The reliance on APIs as a strategic component to business success in the digital economy is well-documented.

    o   Over 60% agree, API Integration is critical to their business strategy. (State of API Integration 2018)

    o   More than 50% of all B2B collaboration will take place via API integration. (State of API Integration 2018)

    o   51% cite ‘partnering with external organizations’ as a leading driver in their decision to develop APIs.
        (State of the API 2019) 

The reliance of business and modern application architectures like microservices on APIs makes them a particularly attractive target for attackers who understand the value of gaining access—or control—over these endpoints. This risk means more attention should be paid to the API layer, particularly on securing access to the business functions they represent.

Authentication is not Optional

Security for APIs starts with access. And that means authentication. Open APIs should not be a description of an API access model. It's an attribute that means the API is well documented and follows a standard. Invocation of APIs should always require authentication and, optimally, authorization.

There are several options available and before you choose you should make yourself aware of the capabilities and limitations of each.

• GOOD: HTTP Basic
  HTTP Basic Auth is the default. It's the simplest and most common way to enforce authentication of HTTP-based traffic, such as most APIs today. The downside to Basic Auth is that it requires credentials and, as we are all aware, credentials are often shared across multiple applications. Stolen (or exposed) credentials are increasingly the path taken by attackers to obtain access to systems. Strength of passwords and where/how they are stored also factor in to the overall security of this method. It's better than nothing.
• BETTER: API Keys
  API keys are a step above HTTP Basic Auth because they are issued (and one assumes, tracked) by the issuer. API keys are doled out and used for various purposes beyond security, including metering and billing. They are generally static, however, which means that they could potentially be extracted and used by a third party to impersonate a legitimate user. Sharing keys, too, is a real issue. Like credentials, keys can and are shared by co-workers and family. And the more they're spread around, the more likely they are to be picked up and used by someone with malicious intentions.
• BEST: Expiring Tokens
  The use of tokens has become more common as the number of APIs has grown. The two favorites today are OAuth tokens (exclusively used for APIs) and JWT (JSON Web Tokens). The use of JSON as the standard format for exchanging claims about access to HTTP-based resources and its applicability outside APIs has driven JWT to become one of the most prevalent mechanisms for authentication and authorization today. It even has an RFC (7519). Much like its XML cousin, SAML, a JSON assertion is issued that describes the access reach and role of the authenticated user. It's highly portable and, importantly, comes with an expiration date/time so it can't be easily used to impersonate an authenticated user. The downside is that tokens require more work to integrate and aren't always natively supported. This can lead to mistakes in implementation that unintentionally introduce the potential for exploitation.

API security can be implemented directly in an application or, better, in an API Gateway. An API gateway can further protect APIs with capabilities like rate limiting (to prevent accidental or intentional denial of service attacks) and authorization. Authorization narrows access to APIs by allowing access to specific API calls to only specified clients, usually identified by tokens or API keys. An API gateway can also limit the HTTP methods used and log attempts to abuse other methods so you're aware of attempted attacks.

Our reliance on applications means the APIs they rely on need protecting, too. If you haven't already started with the basics, it's time to get going. If you want to protect your business, you're going to need secure APIs.