The Non-Technical User’s Guide to API Security

What is an API?

An API is like a waiter who takes an order at a restaurant and brings the food back to the customer. Just as the waiter needs to ensure that the food is delivered to the right person and that it hasn't been tampered with, an API needs to ensure that data is transmitted securely and not intercepted or modified by unauthorized parties.

This helps explain why APIs are everywhere, with over 40% of large organizations using 250+ APIs.

API Architecture Types

There are several architectural styles for APIs, but 3 of the most popular are:

●       REST (REpresentational State Transfer)

●       SOAP (Simple Object Access Protocol), and

●       GraphQL (Graph Query Language)

SOAP is the oldest, followed by REST and GraphQL, though all 3 are still around and can be used. More detailed information on each of these can be found here.

The architecture largely determines how the APIs need to be secured, and the choice is foundational to how to proceed with APIs.

Know What You’ve Got

Dangerous Types

Two types of APIs to avoid are Zombie (forgotten) and Shadow (unknown) APIs (it makes one think that gamers do a lot of the naming conventions). For many survey respondents, zombie APIs are among the most feared API risks – “nearly triple the rate of any other concern”. When a resource is forgotten or unknown, it’s not secured. When that happens, it’s only a matter of time before a criminal finds it and capitalizes it.

What are the risks?

Back to the waiter analogy: the waiter doesn’t cook the food or know the recipes, so trying to get the secret sauce recipe directly from the waiter wouldn’t reveal much. But if the waiter can be delayed, bribed, or frustrated, that would negatively affect the business.

Criminals can’t necessarily get anything directly from an API, but using the API in a way not intended (called API abuse) can give information that they shouldn’t be able to access, such as sensitive personal or corporate data, and resulting in financial loss, reputational damage, or even legal trouble.

Here’s a list of some specific risks:

Unauthorized Access

One of the most significant risks associated with APIs is unauthorized access. APIs can provide access to sensitive data (e.g., PII (personally identifiable information), financial data), which can be exploited by bad actors when not properly secured. Attackers will try to exploit vulnerabilities in the authentication or authorization mechanisms by pretending to be someone else.

Injection Attacks

Injection attacks occur when an attacker inputs malicious code to the API's input fields, which can then be executed on the server. This can result in data loss, data corruption, or system compromise.

Denial of Service (DoS) Attacks

DoS attacks are a common threat to APIs, where an attacker overloads the system by sending a high volume of requests. This can cause the API to crash, resulting in service disruption or downtime.

Insufficient Logging, Monitoring, and Alerting

APIs need to be properly logged and monitored to detect and respond to security incidents. Here’s the waiter again: the manager needs to keep an eye on the wait staff to ensure they’re not overwhelmed to the point of making dangerous mistakes. If logging, monitoring, and alerting aren’t implemented or maintained, the difficulty in detecting and responding to security incidents only increases, which then increases the risk of data loss or system compromise.

What are good security measures?

These can also be called security controls. APIs use encryption to ensure that data is transmitted securely and that authentication and authorization protocols are used to ensure that only authorized users can access the API.

Authentication

APIs can use authentication mechanisms, such as OAuth or API keys, to ensure that only authorized users or applications can access the API. This can help prevent unauthorized access and protect sensitive data.

Encryption

APIs need encryption, such as SSL/TLS, to secure data in transit between the client and the server. This helps prevent eavesdropping and data theft.

Authorization

APIs should use authorization mechanisms, such as RBAC (Role-Based Access Control) or ABAC (Attribute-Based Access Control), to control what actions authorized users can perform within the API. This helps prevent malicious actors from accessing sensitive data or performing malicious actions.

Input validation

Use input validation techniques, such as data validation, to ensure that the data input by users or applications is in the correct format and free of malicious code. This mitigates any damage from injection attacks and other attacks that exploit input validation vulnerabilities.

Rate Limiting

Rate Limiting limits the number of requests a user or application can make to the API within a specific period. This can help prevent DoS attacks and protect against service disruption.

Monitoring, Logging, and Alerting

Monitoring and logging are used to detect and respond to security incidents. Often it’s mentioned as just logging and monitoring, but I always like to include “alerting” because that’s the purpose of the first two actions. This helps identify potential threats and vulnerabilities and provides a record of any security incidents that occur.

Regular Auditing and Vulnerability Assessments

APIs should be audited and assessed regularly to ensure that security measures are up-to-date and that vulnerabilities are addressed.

Applying Threat Protection

Keep in mind that when it comes to API security, pre-production testing has its limits. Most API attacks are business logic attacks, and gaps in business logic are hard to detect with pre-prod testing. Organizations should plan to complement their API security testing with threat protection deployed at runtime for a full security solution.

Real World Example

A quick example to show how a little bit of insecurity can lead to big trouble. The Texas Department of Insurance. The web service (aka API) allowed the public access to the private records of 1.8 million workers. Though unintended, the “glitch in the code” is categorized as Broken Function Level Authorization.  Other great API breach and data leak examples can be read here.

What’s Next?

Everyone who interacts with an API, whether a developer, a user, or a business owner, is responsible for ensuring that the API is secured properly to protect sensitive data and prevent malicious activity.

OWASP (Open Web Application Security Project) lists the top ten API security risks here, though the next draft is expected to be finalized in 2023.

One of the most important security tools is the right mindset. APIs can be protected – it’s not an out-of-reach goal. There are numerous free and paid tools that will assist data defenders in carrying out their security initiatives.