Application Programming Interfaces (APIs) are central to digital transformation and business innovation, allowing companies to create new products and services for customers. But as with every good thing, there are also challenges. APIs are great connectors, but these connections pose certain risks. Rarely a week passes without news about another API attack. Unfortunately, this cannot be viewed as just a warning anymore. Since API breaches can lead to dangerous consequences, they definitely should not be overlooked. API security should be a priority for anyone developing APIs or integrating them into applications.

Although the need to improve API security is often discussed, many organizations still fail to prioritize it. You may have read about big players like Tesla or Peloton going through API breaches. But if API attacks of all scales were reported on the same level, the importance of protecting APIs would become crystal clear.

In this article, I will highlight the key considerations for API security. By following these core principles, organizations and developers can ensure the safety of their systems and mitigate the risks of becoming the subject of the next API breach.

1. Make Sure to Protect All APIs

APIs can be divided into two categories: external and internal APIs. Judging by the names, it may seem that the external ones should be protected better than internal ones — just like the doors to your house require secure locks. However, when it comes to API security, it really does not matter whether the API is exposed to the external environment or not. It should always be protected. This aligns with a zero-trust architecture where the shift from a network-based perimeter to an identity-based perimeter requires all access to an API to be verified.

External APIs that integrate applications with third-party resources may seem more prone to attacks. Failure to set up authentication and authorization can lead to third-party agents gaining access to internal data. Though this data might not be too sensitive, the leaked information could be used to deepen the breach and launch a phishing attack to get ahold of much more critical user and system data.

However, it is crucial to remember that internal APIs can be as vulnerable as external ones. These APIs are widely used to access resources within the system and link internal applications. But the mere fact that they are positioned within the system perimeter doesn’t make them more protected. Therefore, the recommendation is to protect all APIs. Attacks might come from inside — attackers might discover your APIs when created for internal use and then published externally. Also, it is not uncommon for external actors to first breach the perimeter security and then penetrate deeper into the infrastructure because internal services are unprotected.

2. Always Use an API Gateway and a Central OAuth Server

An API gateway is a tool that ensures that access to backend services is authenticated and authorized. It also helps centralize common features used across APIs. The gateway can standardize interactions with your APIs and serve as a single entry point. Standard API gateway features include rate limiting, blocking malicious clients, proper logging, path and headers rewriting, and gathering business metrics. Without a gateway, API providers would have to reinforce each endpoint with various features one by one, and in case one is missed, it could lead to serious security gaps.

To fulfill most of these features, the API gateway needs proof of who the caller is. This verification is commonly handled in a token-based manner where the token represents the end user and includes information about the client application. Such tokens can be obtained in different ways, but currently, one of the most popular and secure methods is to use OAuth 2.0 and OpenID Connect standards to define how tokens are issued. Once these tokens are issued and presented to the API gateway, they must be validated. There are various patterns for validating different token types, but most modern API gateways in the market can handle this. At a minimum, the token’s expiration should be validated, and it is also typical to check that the token is issued for the correct audience by validating the aud claim.

In summary, placing your APIs — both public and internal — behind a gateway will allow you to increase security. However, it is vital to ensure that your API gateway does not issue tokens. Instead, a central OAuth server should issue tokens since it implements many complex processes like client and user authentication, client authorization, token signing, and more. These procedures involve handling a lot of data and many keys used to sign the issued credentials. Such tasks should only be performed by the OAuth server. Centralizing the management of credentials and token issuance will allow you to mitigate the risks associated with ad hoc solutions and patches.

3. Use Access Tokens Wisely

A modern token-based architecture is great for protecting APIs. Tokens help establish trust and ensure APIs have enough information to make proper access decisions. However, to fully reap the benefits and secure your system, it is of the utmost importance to use each different token type correctly.

JSON Web Tokens (or JWTs) has become one of the most widely used formats for access tokens as they are easy to use and can be validated by the service itself. However, while using JWTs as access and refresh tokens is considered good practice, remember that they should only be used internally. When tokens are exposed outside of your infrastructure to third-party clients, you should use opaque tokens instead of JWTs.

There are a few reasons why opaque tokens are considered more secure than JWTs. Firstly is their nature — they are opaque strings that do not have any meaning to the client. When it receives an opaque token, it must call the issuer to verify the token and get the data. On the other hand, when JWTs are used, the receiver is not required to call the issuer, so it is impossible to revoke a JWT. It is also highly likely that a JWT contains some personally identifiable information (PII) that the application itself should not consume and is intended for the API, hence why JWTs are more appropriate for internal use.

Some other token-handling best practices to follow are:

• Always verify incoming JWTs.
• Create or reuse libraries for JWT validation.
• Don’t use JWTs for session handling.
• Use opaque tokens for external or public clients.

Proper usage of tokens is an integral part of your API security. Follow the best practices created by security professionals.

4. Limit Trust on Incoming Traffic

Consider applying a zero-trust approach to your APIs. Establishing a zero-trust architecture means creating a system where no one is trusted and any user or service accessing data is always verified. A zero-trust architecture is not a single architecture in itself — it is a set of guidelines for designing systems and operations that intend to tighten the security to protect enterprise assets.

Authentication is critical to any successful implementation of a zero-trust architecture. For example, it is vital to determine whether the user is internal, what part of the organization the user belongs to, what service is requesting information from another service, and what third-party service is requesting access to an internal corporate service.

Limiting trust on incoming traffic can be done by using HTTPS (even internally) and verifying all incoming JWTs, even those transformed from an opaque token by the gateway. This will prevent malicious actors from operating inside your infrastructure.

5. Always Test, Monitor, and Audit

To make your APIs and the whole system really effective against security threats, it is essential to continuously test and monitor which APIs or endpoints pose a risk. The vulnerabilities must be identified in the initial phase so that correcting them can be relatively easy and quick.

Setting up security measures aimed to protect your APIs should be followed by establishing governance over them. It is always a good idea to have a dedicated team of experts actively monitoring and auditing your API security system. These people should gather metrics, log API usage, and check unexpected requests or unusual client behavior. This will allow you to catch a breach before it harms your system, keeping your organization’s assets and user data safe.

Conclusion

As APIs continue to grow in importance, maintaining high-standard API security is a paramount concern. As such, keeping APIs and the data flowing through them safe and only accessible to the intended user is a must. This is not something to wait on — if you haven’t already, you need to get on it now.

Remember to protect both external and internal APIs, leverage API gateways, use a central OAuth server, regularly verify incoming traffic, and continuously audit your system. There are many technical strategies to consider when managing API authentication and authorization. Following the best practices can help you safeguard APIs and thwart unwanted behavior.