---
title: REST API protection from DoS and DDoS
description: Flow control protects REST application programming interface (API) servers from denial-of service (DoS) and distributed denial-of-service (DDoS) attacks using four control variables, which are independently configured. By default, no flow control is enabled.
component: pingintelligence
version: 5.2
page_id: pingintelligence:pingintelligence_reference_guide:pingintelligence_rest_api_protection_dos_ddos
canonical_url: https://docs.pingidentity.com/pingintelligence/5.2/pingintelligence_reference_guide/pingintelligence_rest_api_protection_dos_ddos.html
revdate: April 3, 2024
section_ids:
  example: Example
---

# REST API protection from DoS and DDoS

Flow control protects REST application programming interface (API) *(tooltip: \<div class="paragraph">
\<p>A specification of interactions available for building software to access an application or service.\</p>
\</div>)* servers from denial-of service (DoS) and distributed denial-of-service (DDoS) attacks using four control variables, which are independently configured. By default, no flow control is enabled.

The following table shows the control variables that are configured once in every API JavaScript Object Notation (JSON) *(tooltip: \<div class="paragraph">
\<p>An open, lightweight data-interchange format that uses human-readable text to store and transmit data.\</p>
\</div>)* file.

| Variable                     | Description                                                                                                                     |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| `client_spike_threshold`     | Maximum requests per time-period from a single client IP to a specific REST API.Time can be in seconds, minutes, or hours.      |
| `server_connection_queueing` | When `true`, queue API connection requests when all backend servers reach server connection quota.The default value is `false`. |

The following table shows the control variables that are configured for each server in every API JSON file.

| Variable                  | Description                                                                                                                                                                                                                                                  |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `server_connection_quota` | Maximum number of concurrent connections to a specific REST API on a server. Prevents aggregate connections from one or a cluster of API Security Enforcer (ASE) nodes from overloading a REST API running on a specific server.                             |
| `server_spike_threshold`  | Maximum requests per time period to the REST API running on the specified server. Prevents the aggregate request rate from one or a cluster of ASE nodes from overloading a REST API running on a specific server.Time can be in seconds, minutes, or hours. |

The following diagram shows the effect of the parameters on traffic flow through ASE to backend servers. In the diagram, client-side flow control is managed by the `client_spike_threshold` parameter and server-side flow control is regulated by a combination of the `server_spike_threshold` and `server_connection_quota` parameters.

![Diagram showing flow control management in ASE.](../_images/bdz1615891119936.png)

Client flow control monitors incoming traffic from each client connection and drops the session when traffic limits are exceeded. The diagram shows the following client scenarios:

* IP1 sends request volumes that exceed the `client_spike_threshold` value. ASE 1 sends an error message and terminates the session to stop the attack.

* IP2 and IP3 sends request traffic that stays below the `client_spike_threshold` value. Requests are passed to the backend API servers.

Server-side flow control manages traffic volumes and session count for an API on an application server. `server_connection_quota` sets the maximum number of concurrent connections that can be established to each API on a server. `server_spike_threshold` controls the aggregate traffic rate to an API on a server.

The concurrent connections and request rate consist of the aggregate traffic from all ASE nodes forwarding traffic to an API on a server. The diagram shows two server scenarios:

* A new connection request from ASE 1 is allowed because it's within the `server_connection_quota` threshold.

* ASE 2 detects that the combined traffic rate from ASE 1 and ASE 2 will exceed the `server_spike_threshold` for REST API 1. It drops IP 3 traffic and sends an error message to the client.

## Example

The following is an example for an application server that explains the scenarios depicted by the previous diagram.

| Parameter                    | Configured value                         |
| ---------------------------- | ---------------------------------------- |
| `client_spike_threshold`     | 50,000 requests per second per IP        |
| `server_spike_threshold`     | 30,0000 requests per second per server   |
| `server_connection_quota`    | 20,000 concurrent connections per server |
| `server_connection_queueing` | `true`                                   |

* Client flow control permits a maximum of 50,000 requests per second from an individual IP. If IP 1, 2, or 3 exceeds the 50,000 per second limit, ASE drops the client session. Otherwise, all requests are passed to the backend servers.

* Server flow control allows 30,000 requests per second to REST API 1 on the application server. If the sum of requests per second from the ASE cluster nodes (ASE 1 + ASE 2 request rate) to REST API1 exceeds 30,000 per second, then traffic is dropped from the client causing aggregate traffic to exceed the maximum request rate. Otherwise, ASE 1 and ASE 2 forward all traffic.

* Server flow control allows 20,000 concurrent connections to REST API1 on the application server. If the sum of connections from the ASE cluster nodes (ASE 1 + ASE 2 connection count) to REST API1 exceeds 20,000, then ASE will queue the request for a time because `server_connection_queuing` is enabled. If queuing is not enabled, then the request is dropped.

**Summary table for REST API flow control**

| Parameter                 | Notes                                                                                       |
| ------------------------- | ------------------------------------------------------------------------------------------- |
| `client_spike_threshold`  | Maximum request rate from a client to an API                                                |
| `server_spike_threshold`  | Maximum aggregate request rate through ASE cluster nodes to an API on a specific server     |
| `server_connection_quota` | Maximum number of concurrent sessions from ASE cluster nodes to an API on a specific server |

|   |                                                                                                               |
| - | ------------------------------------------------------------------------------------------------------------- |
|   | You can also configure server connection quota and server spike threshold separately for each backend server. |
