To illustrate how API works and why API security is of paramount importance, let’s bring up the “waiter/waitress = API” analogy.
You are sitting at a restaurant reading the menu and waiting for someone to come and take your order. The waiter “or API” is the messenger that provides the interaction between kitchen “server/system” and customer. The waiter takes the order to the kitchen and brings back the food to you. You request a web service via an app; the API takes it to the system/database or the API server. The server responds, and the API brings back the response to the client’s app.
But what would happen if the waiter needs to travel through risky places. What would happen if it gets intercepted and robbed by a couple of thieves? The waiter could either be impersonated by one of the thieves, your food order modified, your worst of all, stolen or destroyed.
Implementing API security is like protecting that “waitress or waiter” carrying your sensitive information across unsafe and risky networks.
In this guide, we’ll go deep into API security, how to protect your assets, best practices, methods, and best tools to implement it.
Table of contents
- What is API security?
- SOAP API vs. REST API Security
- API Security’s vulnerabilities
- The API Security Best Practices
- Audit and Test your APIs
- Use an API Gateway
- Employ a Central OAuth server
- Adopt the zero-trust strategy
- Use JSON Web Tokens (JWT) for an internal network
- Limit resources: API throttling and rate-limiting
- Use API Security Tools
- API Security testing tools
- API Gateways and Web Application Firewalls (WAF)
- Final Words
1. What is API Security?
APIs are all around, externally and internally, small or large. Their job is to handle and expose all kinds of data, including sensitive like Personally Identifiable Information (PII). So. APIs are generally primary attack targets.
API security is the practice, process, or measures taken to ensure that the current state of an API is free from risk, threats, or vulnerabilities. It is achieved using several simultaneous strategies or a combination of them. Examples of these methods are, using an API gateway, tailoring access control, using an authentication and authorization server, and more. Without API security, modern mobile, SaaS, and web applications wouldn’t be possible.
a. SOAP API vs. Rest API Security
There are generally different ways to provide web services, but the most popular is via either two different API architectures: SOAP and REST API. SOAP has its language, its platform and doesn’t depend on transport. On the other hand, REST is more straightforward and uses third-party protocols like HTTPS for transport or JSON for message formating.
Naturally, both API (SOAP and REST) methods expose data when using HTTP requests and responses. However, they use widely different semantics and formats, so their security considerations and requirements differ.
Here are a few differences:
- Built-in security capabilities SOAP API provides protocol extensions that address security. For instance, SOAP includes XML encryption, SAML tokens, and XML signatures. REST APIs, on the other hand, do not include built-in security. With REST APIs, the developer must implement security for deployment, transmission, and client interaction.
- Encryption Both SOAP and REST APIs support SSL/TLS when making a request. To extend security, SOAP supports Web Services Security (WSS) to provide enterprise-grade security along with SSL. REST services do not offer support for WSS.
- Error detection and control SOAP supports WS-ReliableMessaging, to deal with errors. REST APIs, on the other hand, have no built-in mechanism to deal with mistakes. They need to send the data again after an error occurs.
Due to protocol design, SOAP APIs tend to be more secure than REST APIs. But that doesn’t mean REST APIs are insecure. When it comes to web services, the modern and more straightforward REST API is generally preferred. As a result, SOAP is chosen in enterprise implementations. In addition, since REST APIs are more flexible, they can be configured to be as secure as SOAP APIs.
b. API Security’s Vulnerabilities
Most of the time, APIs are doing their job without a proper prior test and security assessment. Unfortunately, untested (and even tested) APIs are faced with vulnerabilities, which you have to keep in mind. APIs have similar vulnerabilities as web applications. According to OWASP Top ten’s API vulnerabilities from 2019:
- Broken object-level authorization. APIs create a large attack surface when they expose endpoints handling object identifiers.
- Broken function-level authorization. An unclear and complex division between administrative and ordinary functions may lead to authorization flaws.
- Excessive data exposure. When developers design APIs, they tend to expose all the object properties.
- Lack of resources and rate-limiting. Many APIs do not limit the size or number of requested resources made by the API client. Without rate-limiting, an API server may be subject to lower performance or, even worst, to DDoS attacks.
- Broken user authentication. When authentication is weak and incorrectly implemented, attackers may steal authentication tokens or exploit flaws.
- Mass assignment. Without properties filtering, an API client providing data to a data model may lead to a mass project. For instance, an attacker might use JSON to explore different API endpoints or provide additional object properties (outside what’s necessary).
- Security misconfiguration. Errors or faults in the configuration that result from insecure default, insufficient, or unnecessary settings.
- Injection. Just like a website, an API is also vulnerable to SQL injection attacks. An SQL injection is when an attacker crafts a fake SQL statement and inputs it to trick the database into returning information.
- Improper assets management. APIs expose more endpoints than traditional web applications. So, they must be adequately managed to avoid issues like exposed debug endpoints or deprecated API versions.
- Insufficient logging and monitoring. Unattended API security leads attackers to pursue other attack vectors, persist on a current attack, perform a multi-attack vector, or exfiltrate and destroy sensitive data.
API security should be tested across the rest of the entire API lifecycle. This is the only way to identify and address those API vulnerabilities. So test APIs continuously and routinely to identify vulnerabilities. We’ll mention some API testing tools at the end that will help identify these vulnerabilities automatically.
2. The API Security Best Practices
If not treated in an urgent manner, these API vulnerabilities can create havoc on your app, database, and client’s data. Fortunately, there are some best practices that you can follow to improve your API’s security standpoint.
a. Audit and test your APIs
Although security gets its phase in the lifecycle of an API, according to RedHat Developers, security should be kept in mind and tested throughout the entire API lifecycle. It is also recommended to test the API internally, with all the necessary protection, before going public. Once an APIs is published externally, they are vulnerable and exposed to a large degree of vulnerabilities. Additionally, assigning a team of API experts to review and audit the security considerations is always a good security practice.
Use Dynamic Application Security Testing (DAST) to add dynamic testing of your web APIs to your CI/CD pipeline. DAST comes with a scanning engine that supports REST, SOAP, GraphQL, and generic APIs.
b. Use an API gateway.
A best security practice is to deploy the API behind an API gateway. This API gateway serves as a reverse proxy, protecting the API server from all traffic from untrusted networks. The API clients forward the API calls to the API server via the API gateway.
With an API gateway, APIs can be protected with rate limitations, block specific clients (based on IP), and provide proper logging, filtering, and monitoring. The API gateway can also be configured to re-write specific HTTP header fields (such as Via and Forward) to protect the identity of the API server. And, if for some reason, an attacker slips a malicious request pass through the API gateway, fine-grained access control at the API level should be able to identify it and stop it.
c. Employ a central OAuth server
A vital component for API security is the authentication and authorization for access control. Rather than letting your API or API gateway handle the access or refresh tokens, it is recommended to use a centralized OAuth Server to take care of these tokens. OAuth is a token-based authentication framework used to control access for third-party services. Use the OAuth server as the single entity in charge to issue and sign tokens.
In addition, you can use Scope, a mechanism from OAuth 2.0, to limit the amount of access to an application to a user’s account. OAuth Scope limits the capabilities of an access token issued to the application. For instance, an access token created for a client app may be configured with READ and WRITE access. Slack, GitHub, and Google APIs use OAuth 2.0 Scopes to limit access.
d. Adopt the zero-trust strategy
There is no way around this. Your API should not trust incoming traffic, especially from public “untrusted” networks, such as the Internet. Public APIs are accessed via the Internet by users worldwide to access and transfer all kinds of data.
To begin implementing a zero-trust approach, start using encryption in transit via HTTPS (TLS) for public APIs. It is even advised to use HTTPS traffic for APIs within internal networks because it can easily be sniffed. Also, employ encryption for data at rest. Encryption for this data can be vital if the API server gets compromised. The zero-trust approach also means always to authenticate users regardless they are outside or inside network perimeters. Also, provide robust role-based access control with the least privilege.
e. Use JSON Web Tokens (JWT) for an internal network
Token-based authentication ensures that every request to an API server travels with a signed token. The API server verifies the signed token to ensure authenticity and then responds to the client’s API request. Using JSON Web Tokens (JWT) as access and refresh authentication tokens is a good security practice for an internal (server-client) infrastructure.
JSON Web Token (JWT) is an open standard defined by the RFC 7519. JWTs are signed using a secret or with a public/private key pair. When using JWT, create a corporate-wide solution to validate JWT rather than segregated” group-based JWT validation. Avoid using JWT outside the infrastructure (i.e., Public APIs). To use outside, when data is public, use opaque tokens.
f. Limit resources: API throttling and rate-limiting
APIs were designed to serve web services, so they have become a primary target of Denial of Service (DoS) or Distributed DoS (DDoS.) When it comes to APIs, never give full access to your resources, as they can be easily exploited.
For instance, a malformed or supersized HTTP request wouldn’t hurt the resources of an API server, but an army of bots amplifying the traffic with more malformed HTTP requests would bring down even the most powerful server. To protect your API server from this type of dangerous volumetric traffic, set the rate limit for the method and frequency of API calls. When an API client starts sending too many or large requests, their connection gets automatically throttled.
3. Use API Security Tools
API security tools are not a one-size-fits-all solution. The majority of the API security tool market focuses on testing and vulnerability assessment, while others, such as WAFs or API gateways, focus on filtering API calls or rate-limiting. In addition, not all tools work with REST, SOAP, or even GraphQL APIs. It is common to see newer tools working only with REST or GraphQL APIs and some others (enterprise tools) only working with SOAP APIs.
a. API Security testing tools
Below are six popular API security testing tools.
It is a free and open-source cross-platform API and web services testing solution. SOAPUI is an automated testing tool for SOAP and REST APIs. It allows you to create and run automated functional regression and load API tests.
A tool built that uses the OpenAPI specification to audit and pen-test APIs. Swagger Inspector is built for developers and QA testers to help them manually inspect the APIs in the cloud. While Swagger’s ReadyAPI is the tool that helps accelerate API security and performance testing.
Astra is an open-source, REST API automated security pen-testing tool. It is used in the API development cycle to detect vulnerabilities and patch them immediately. Astra can also test authentication API by automatically seeing and testing login and logout procedures.
An Apache open-source project designed for performance and load testing. The JMeter can simulate heavy loads (Web, SOAP, REST, FTP, TCP, etc.) on servers, networks, or objects and analyze the performance of web services, APIs, and applications.
An API platform designed to simplify each step of the API’s lifecycle and help build and run APIs easier. It comes with a complete set of tools to help accelerate the API’s lifecycle. Postman is famous for its API testing. It enables you to create a secure and governed API testing environment with Single Sign-On (SSO), user-based access control, audit logs, and more.
It is a comprehensive test automation solution for Web, API, mobile, desktop, and more. Katalon is quite robust when it comes to testing APIs. It supports all types of REST, SOAP/1.1, SOAP/1.2 requests. In addition, the platform helps you validate encryption methodologies, API access control, authorization, and rights to resources.
b. API Gateways and Web Application Firewalls (WAF)
Below are two popular API gateways and two WAFs that identify and filter API calls.
1. Imperva WAF
A WAF that provides security through the entire Web Application and API Protection (WAAP) stack. It comes out of the box with security rules that adjust to the needs of your APIs. Imperva WAF secures and filters the traffic from the edge device to the database. Its advanced analytics and automated security protect the OWASP Top 10 API vulnerabilities when it comes to vulnerability assessment.
A fully AWS managed service that helps developers create, publish, maintain, monitor, and secure APIs. Amazon’s API Gateway can centralize the processing and validation of many simultaneous API calls, manage/control traffic, throttle, and limit rate (to avoid DDoS), monitor, and provide authorization and access control.
NGINX API Gateway is a popular API gateway that helps improve your API security standpoint. NGINX API gateway provides:
- Rate-limiting and throttling policies.
- A fine-grained access control (authorization and authentication via JWTs),
- Enforces particular request methods (for instance, accept GET method with read-only).
In addition, use the NGINX controller to manage API gateways, authentication/authorization, rate limits, API versioning, and more.
A WAF built to protect your web applications and APIs. It achieves API security by automatically detecting, fixing vulnerabilities, and stopping attacks. F5 Advanced WAF protects against the OWASP TOP 10 Web app and API vulnerabilities and beyond by protecting applications against software vulnerabilities. F5 Advanced WAF also provides API inspection, malicious botnet protection, behavior analytics, and more.
Given the popularity of APIs and the level of access they provide to sensitive data and systems, they are valuable targets for attack. As a result, APIs are considered to be the next top attack vector.
To protect your APIs, use the API security best practices described in this post. Also, using one of the API testing tools described plus an API gateway will help you keep attackers under your shoe.