API security

What are the most common API security threats and vulnerabilities?

APIs are crucial to the success of modern businesses and have therefore emerged as a primary attack target. The Open Web Application Security Project (OWASP) already maintains a top ten list of general security threats to web applications, but the growing security threat to APIs led OWASP to create a dedicated project to track the top ten most critical API security risks. These two lists address a wide range of vulnerabilities, which can be broken down into the following categories:

Poor security hygiene

This is the most basic category of security vulnerabilities, but it is also one of the most important. Failure to maintain good security hygiene can lead to major breaches that could have easily been prevented. For instance, teams should ensure that their tokens and API keys are not hard-coded or included in their API client libraries' source code, Git history, or documentation. They should also use Transport Layer Security (TLS) to encrypt all API communications, whether the API is delivered as an HTTP-based REST API or a Protobuf-based gRPC API.

Authentication and authorization vulnerabilities

APIs often give users different permissions depending on their role. Authentication and authorization issues therefore pose a significant security threat because they enable users to perform actions and access data that should be restricted.

There are many ways for these issues to enter an API. For instance, organizations might fail to perform method-level authorization checks to confirm that the object being read or written to is within the user's authorization scope. Additionally, if authorization is scoped by API endpoints but individual objects have more granular permissions, there is a risk that improperly-checked permissions could result in access violations (this is related to the following vulnerability: lack of read and write granularity). Teams might also fail to use cryptographic methods, such as public key encryption, in user authentication workflows, which introduces the risk of spoofing.

Lack of read and write granularity

Data objects have many properties—some of which are sensitive, and some of which are not. For example, an instance of a User object may have a username property (which is not sensitive) and a password property (which is sensitive). Sometimes, developers fail to protect sensitive properties on the server side and instead rely on clients to filter them out, which leaves them accessible to malicious parties. This vulnerability is known as excessive data exposure.

Similarly, users should not be able to update internal properties (such as user.id) and permission-related properties (such as user.is_admin). Unfortunately, developers sometimes introduce a mass assignment vulnerability by programming an API to simultaneously assign every piece of data it receives from a client. Instead, developers should implement logic that checks each property and only assigns a new value to properties that can be updated by the user in question.

Failure to implement quotas and throttling

Quotas and throttling are intended to limit the number of requests to a particular service in order to conserve computational resources and ensure high availability. APIs that don't implement quotas or throttling can leave applications vulnerable to brute force attacks, in which an attacker systematically guesses a password in order to gain access, and Denial of Service (DoS) attacks, in which an attacker floods an API with traffic in order to exhaust the resources of a downstream service and take it offline.

Improperly set or missing HTTP headers

When a web client sends an initial request to an API, the response should have appropriate HTTP headers, including security headers. Security headers give the browser instructions for safely interacting with the API. For instance, HTTP Strict Transport Security (HSTS) headers can be used to enforce valid certificates and TLS communication, and Access-Control and Cross-Origin Resource Policy (CORP) headers can prevent a valid client from being misused to perform API requests on behalf of potentially malicious third-parties.

Additionally, improperly set headers, such as the Cache-Control and Vary headers, can result in private data leaking to other API clients if proxies or load balancers are used in front of the web server.

Failure to perform input validation, sanitization, and encoding at the method level

API injection occurs when an attacker sends malicious code through an API, often within a request's parameters or body. This malicious code might be executed on the server side (for example, in a SQL query or during the deserialization of data), or it may be executed on the client side if it gets embedded in HTML content and it was not properly escaped beforehand. This malicious code might then change permissions or database records that should be protected, or even result in arbitrary remote code execution (RCE). It's therefore crucial for developers to leverage Web Application Firewalls (WAFs) and perform input validation, sanitization, and encoding at the method level, which will prevent any malformed or unsafe data from entering the workflow. Libraries like OWASP's ESAPI can help reduce the occurrence of this vulnerability.

Inaccurate inventory and documentation

Teams are often responsible for numerous API artifacts, such as endpoints, versions, and third-party services. But as these artifacts multiply, it becomes increasingly difficult to document and manage them securely. For instance, if a team forgets to retire an old API version, hackers may be able to exploit a vulnerability that was subsequently patched. This issue, which is known as improper assets management, is compounded when teams fail to maintain up-to-date documentation that adequately documents every API asset and its role in the larger system.

Inadequate logging and monitoring practices

Logs record the details of all system activity, so it's important to enable logging for every service and infrastructure component in your environment—including APIs. But even small systems can generate millions of logs a day, making it extremely difficult to identify suspicious activity in a timely manner. Logs may also contain sensitive data, which needs to be handled appropriately to ensure security and compliance. Teams should therefore augment their logging practices with a robust monitoring strategy in order to surface security breaches and sensitive data in their log stream.

Which API security vulnerabilities are most relevant to other types of API architectures?

While REST remains the most popular API architecture, some developers choose to leverage SOAP, GraphQL, WebSockets, or gRPC to support their specific use cases. Each of these architectures has its own security concerns, which we will explore in this section.

• SOAP: SOAP, which stands for Simple Object Access Protocol, is an XML-based messaging protocol. XML processing modules, however, may not be secure against maliciously constructed data, so it's important to use the most up-to-date libraries in order to secure your API and its downstream services. SOAP APIs may also use serialization in remote procedure calls, which gives attackers the opportunity to hide malicious code in requests.
• GraphQL: GraphQL is a query language that enables users to connect and interact with disparate data sources through a single API endpoint. Because GraphQL is used to connect multiple data sources, a seemingly simple request may require significant downstream processing, or have wide-ranging read/write impacts that violate access permissions. This makes quotas and throttling, as well as permission granularity, especially important in GraphQL-based architectures.
• WebSockets: WebSockets allow for continuous, bidirectional communication between clients and a server over a single TCP connection. WebSockets do not handle authentication or encryption directly, which means that developers must explicitly utilize TLS and check for authorization. Additionally, the same-origin policy does not apply to WebSockets, which has caused a variant of the "Cross-Site Request Forgery" attack pattern (previously tracked by OWASP in 2013) to resurface as "Cross-Site WebSocket Hijacking." WebSocket-based applications are also susceptible to standard web application and API vulnerabilities, so developers must apply the same security methodologies that are relevant in other contexts: rate limiting and anti-CSRF measures, validation and sanitization of inputs and outputs, and checking the Origin header against an allow-list.
• gRPC: gRPC is a Remote Procedure Call (RPC) framework that operates over HTTP/2 and facilitates low-latency communication between polyglot services and clients at scale. Like SOAP, gRPC relies on serialization to transmit data, but it uses Protocol Buffers as the underlying serialization mechanism. Unsafe deserialization can be avoided by using Google's standard Protocol Buffer libraries, but non-standard implementations may have their own security considerations and should therefore be used judiciously.

Why use Postman for API security?

When developing an API security strategy, it's important to use tools that help you avoid exploitable security vulnerabilities while providing full coverage throughout the API lifecycle. With Postman, you can:

• Enforce security rules on API definitions and requests: Postman API Security provides a set of default security rules, based on the OWASP “Top 10” for APIs, which will automatically surface common vulnerabilities and violations in your API landscape.
• Customize security rules to fit your needs: Every organization is different, which is why Postman API Security enables teams to define and import custom rules according to Spectral guidelines.
• Integrate API security checks into your CI/CD pipelines: It's crucial for teams to identify security issues as early as possible, and Postman API Security rules can be automatically run against API definitions at the CI/CD build stage. If any violations occur within the pipeline, they can be used to stop the build and prevent a deployment.
• Monitor API performance and response times: API security can have a direct impact on API performance, and Postman Monitors help you surface issues quickly by providing continuous visibility into API performance and response times.
• Automate security testing to prevent regressions: Postman enables you to write test scripts to automate security testing. For instance, authorization tests can easily be automated with Postman's scripting capabilities. You can also set up Monitors to continuously monitor test results and prevent regressions.
• Implement version control: Postman's collaborative features include version control, which enables teams to keep track of API version history and ensure that the current version remains secure.
• Keep your documentation up-to-date: Postman automatically generates documentation for any collection, as well as for any OpenAPI 3.0 definition. Your documentation will update automatically as you make changes, which will help your team maintain a complete and accurate understanding of the API assets for which they are responsible.