What is API Security?

Your API is the front door to access your organizations data, and increasing numbers of users and services are accessing data through APIs. More users is a good thing, but unfortunately, it often means more security risks as well.

This fact makes API security a critical consideration for any organization with an API. You dont want unauthorized users accessing data or hijacking your entire system when the consequences can mean hundreds of millions of dollars in penalties. But API security is complex. There are many ways that an attacker can gain access to your API, and there are lots of different security strategies. Where should you start to protect your data?

Weve got you covered. Read on to learn more about what API security is, the different types of APIs and API attacks, and the other basics you need to know to keep your API secure.

What is API security?

API security refers to the safeguards you use and the steps you take to keep attackers from gaining unauthorized access to your API. From choosing your APIs architecture to creating targeted defenses against specific API attacks, every part of your API security adds another layer of protection against hackers.

At a high level, API security involves:

• Choosing the architecture and protocols for your API
• Identifying risks
• Safeguarding against those risks

The first choice for API security is a foundational one: whether to use SOAP or REST API.

REST API security vs SOAP security

Two of the most common terms youll hear when describing an API are REST and SOAP. Both are a means to communicate and transfer data, meaning you can use them to create, update, and delete data, but there are differences between the two.

SOAP (Simple Object Access Protocol) is a protocol, which means it has official standards that govern how it can be used. SOAP is older and more complex than REST, but can still be useful for situations where security is paramount over performance because of its built-in security functions. SOAP only operates on HTTP and XML standards.

REST (Representational State Transfer) is not a protocol its an architecture for building APIs. Since its not a protocol, it is more flexible than SOAP when it comes to standards. You can even use the SOAP protocol together with the REST architecture. REST also uses fewer resources and has a lower payload than SOAP, so it results in better performance than SOAP in most cases.

While there are other technical differences between REST and SOAP, the bottom line is: if your top priority is security, you may want to use SOAP. If your top priority is performance, you may want to use REST.

Once youve decided whether to build a RESTful API and whether youll use SOAP protocol, youll want to focus on defending against attacks.

Different types of API security threats

There are lots of ways that attackers can gain access to your API. Whats more, different types of API security threats can overlap one another in definition, which makes it hard to make sense of them and figure out a plan to address them.

Here are the six top concerns that youll want to guard against, and how theyre related to one another:

• Malicious attacks. Malicious attacks are actions that cause deliberate harm. These can include changing, corrupting, or even deleting all data in your system.
• Unauthorized access. Not all attackers are out to destroy your data. Another API security threat is unauthorized access, which means that hackers get access to sensitive data that shouldnt be shared. Just seeing this data can be enough to cause serious damage.
• Injection attacks. Injection attacks are a type of malicious attack or unauthorized access attack (or both). With injection, an attacker passes info to your database that gives them unintended access and/or lets them add or remove data where they shouldnt be able to. For example, an attacker could append the text OR 1=1to a parameter in a GET request to return all data in the table.
• Denial-of-service attacks. Denial of service attacks dont allow unauthorized access to your system. Instead, they send lots of requests to your API in an attempt to overload the system and prevent legitimate users from logging in. This makes them a type of malicious attack.
• Broken authentication and session management. Broken authentication and session management attacks result from brute-force attacks to guess a users password, interception of a users credentials, or forging session info, which results in unauthorized access. Once the attacker has access, they may also perform a malicious attack.
• Lack of encryption. Lack of encryption can make it easier for attackers to succeed with any of the above attacks. Lack of encryption can also lead to man-in-the-middle attacks where attackers intercept the data exchange between the API and the client.

API security breach impacts

Its a nightmare scenario that has played out again and again in recent years: an overlooked security vulnerability in an API leads to a data breach, and its all over the news. It can expose the PII (personally identifiable information) of millions of users, sink a companys reputation overnight, and lead to a major loss of revenue.

Just how much lost revenue, you may wonder? The answer to that is: it depends what data was leaked and how. Data leaks that result in breaches of privacy agreements or laws like HIPAA can cost companies millions.

Some of the most costly API security breaches (that we know about) of 2022 include:

1. Twitter API security breach. Private data in 5.4 million records from Twitters database were available to unauthorized users due to an API vulnerability (in this case, they were authenticated users that shouldnt have been authorized to see other users PII, but they could). The stolen data was then sold on the dark web. The consequences? Twitter was fined $150 million for the lapse in user privacy agreements.
2. Optus API security breach. Private data from 10 million accounts from Australian telco Optus were held hostage by an attacker with a $1 million extortion demand. The security breach resulted from an unsecured public API. This resulted in Optus setting aside $140 million to address the issue, including funds for credit monitoring services and replacement IDs for impacted customers, plus the costs of an independent review.
3. Beetle Eye API security breach. Beetle Eye, an email marketing campaign company, suffered a data breach exposing 7 million customers PII due to a misconfigured AWS S3 bucket that lacked encryption. The consequences have yet to fully shake out, but researchers quoted in Data Breach Today say that ...the maximum fine for mishandling US consumers data is $100 million with the potential arrest of guilty individuals."

These stories reflect the very serious and very real impact a business can face from an API breach. But luckily there are ways to protect against these outcomes.

API security frameworks

In the same way that types of security threats can overlap, API security measures can also overlap, making the topic confusing. Let's explore the options for API security and how they relate to one another.

Aside from the API architecture (REST) and/or protocol (SOAP), you can select an API security framework to help you make decisions about which security features youll use. Think of the security framework as your big-picture approach to API security. Once you select one, it provides guidelines on the security measures you must take to stay in compliance with the framework.

Lets look at some examples for context. Two of the most popular frameworks for API security are Zero Trust and OWASP Top 10.

Zero trust security model

The zero trust security model is a set of guidelines based on the premise that your API should trust no user or device whether theyre inside or outside of your network until theyve authenticated with the API. Its the opposite of innocence until proven guilty, essentially.

Zero trust ensures you can protect against attacks from internal users and attackers that pose as internal users, and its a great strategy whether you do business in the cloud or work in an on-prem network.

Because its a security framework, its more of a set of guidelines and principles to follow when making API security decisions, which means that many common security measures, such as OAuth and token authentication (more on these shortly), can be part of the implementation of your zero trust security model.

OWASP Top 10

The OWASP Top 10 is a list of the top 10 security vulnerabilities for APIs. You can adopt a framework around the OWASP Top 10 by bolstering security in the areas that OWASP identifies as top priorities for API security. This means reading and understanding the list of security vulnerabilities and then selecting security measures that you can implement to protect against them.

The most up-to-date list of OWASP Top 10 vulnerabilities for 2023 are:

1. Broken object-level authorization.
2. Broken user authentication.
3. Broken object-property-level authorization.
4. Unrestricted resource consumption.
5. Broken function-level authorization.
6. Unrestricted access to sensitive business flows.
7. Server-side request forgery.
8. Security misconfiguration.
9. Improper assets management.
10. Unsafe consumption of APIs.

Many of these vulnerabilities are synonymous with the types of attacks we explored earlier. For each numbered item, OWASP provides great examples of what the vulnerability may look like. Heres an example they give for broken object-level authorization:

An automobile manufacturer has enabled remote control of its vehicles via a mobile API for communication with the driver's mobile phone. The API enables the driver to remotely start and stop the engine and lock and unlock the doors. As part of this flow, the user sends the Vehicle Identification Number (VIN) to the API. The API fails to validate that the VIN represents a vehicle that belongs to the logged-in user, which leads to a BOLA vulnerability. An attacker can access vehicles that don't belong to them.

OWASP also provides tips on how to mitigate each vulnerability, which helps you develop your API security strategy. Additionally, in the case of of using LLMs, it is best to get familiar with OWASP AI Security Project as well.

A sound API security strategy

Once youve considered the API security frameworks, you may wonder how you can adopt them yourself. To do that, youll want to create a sound API security strategy that focuses on the elements of the framework you choose.

For zero trust, that would mean focusing on cutting-edge authentication that never assumes trust. For OWASP Top 10, that means focusing on the vulnerabilities listed above.

There are lots of components that can add layers of security for your API and satisfy the guidelines of your API security framework, but some of the most popular are:

• API gateway
• OAuth and OpenID Connect
• Tokens and encryption
• Throttling and quotas

Lets look at each of these individually to understand how they can safeguard your API.

API gateway

As API gateway experts, we may be a little biased. But if youre looking for a security multi-tool for your API, you should use an API gateway.

An API gateway is a tool that sits between clients and your API and enforces API management rules across multiple backend systems. Using an API gateway, you can deploy several of the other popular security layers (authentication/OAuth/token authentication) and access limits (throttling/rate limiting) to deliver many security features in one tool. And if you choose wisely, your API gateway can work across protocols, technologies, and languages.

Most enterprise-level companies with an API use an API gateway because they dont just improve security; they improve the user experience by aggregating responses from multiple services for a one-stop shop.

The remaining safeguards listed below can be implemented ad hoc, but they can be implemented together using an API gateway.

OAuth and OpenID Connect

OAuth is an open-source standard for authorizing users. It uses access tokens to authorize users to access in your API, leveraging authentication from another service to prove their identity (such as logging in via Google). This helps prevent unauthorized access attacks and broken authentication attacks.

While OAuth provides the authorization layer, OpenID Connect provides the authentication layer, adding additional identity and profile information about the logged-in user. Together, using OAuth and OpenID Connect allow you to leverage single sign-on (SSO), which makes logging in easier for users and ensures security for your API.

OAuth and OpenID Connect are much more secure than other methods such as basic authentication. To learn more about the different types of authentication and authorization, see Understanding API Authentication and Authorization.

Tokens and encryption

Not to be confused with the access tokens in OAuth, token authentication uses API tokens to let users authenticate with your API without SSO. They provide access to your API for a limited period of time, after which access is revoked. For security, tokens should be encrypted, which means that its undecipherable until it arrives at its destination and is unencrypted with a key. This protects against unauthorized access and lack of encryption attacks.

Throttling and quotas

Throttling and quotas limit how much data can be transferred to and from your API, and the speed at which it can be transferred. This way, attackers seeking to overwhelm your system with excessive requests are stopped automatically. Youll want to use throttling and quotas to protect against Denial of Service attacks. The easiest and safest way to implement throttling and quotas is with an API gateway.

Putting it all together

As you can see, there are a lot of choices to make when it comes to securing your API. To recap, the basics of API security include:

1. Decide on architecture and protocol (REST and SOAP).
2. Understand the types of API security attacks and their impact on an organization.
3. Choose security framework(s).
4. Create an API security strategy.

But theres another element that we havent explored: identifying the top priorities for your organization. This will help you triage which of these security practices you most urgently need to adopt.

Here are some general guidelines to get you started:

• If youre an enterprise-level organization or working with very sensitive PII/PHI (personal health information), use as many of the safeguards in this article as you can. SOAP in particular may be a good fit due to its enhanced security, and an API gateway can consolidate the work involved in carrying out a multi-pronged security framework.
• If youre a small organization that needs its API to be optimally performant or you handle less sensitive data, consider a REST API and either token authentication or OAuth.

\When in doubt, go with the more secure option. Securing your API is well worth the effort, and armed with this info on API security basics you can start developing your own security strategy.

However, if youre looking for an API security team to do the heavy lifting for you, wed love to chat! Kongs API gateway can strengthen your API security.