Skip to content

Configuration of BOLA (IDOR) protection

Behavioral attacks such as Broken Object Level Authorization (BOLA) exploit the vulnerability of the same name. This vulnerability allows an attacker to access an object by its identifier via an API request and either get or modify its data bypassing an authorization mechanism. This article instructs you on protecting your applications against the BOLA attacks.

By default, Wallarm automatically discovers only vulnerabilities of the BOLA type (also known as IDOR) but does not detect its exploitation attempts. To configure Wallarm to detect and block the BOLA attacks, use the BOLA trigger as described below.

BOLA protection restrictions

Only Wallarm node 4.2 and above supports the BOLA attack detection.

Wallarm node 4.2 and above analyzes only the following requests for the BOLA attack signs:

Configuration steps

  1. If the filtering node is deployed behind a proxy server or load balancer, configure displaying of a real IP address of the client.

  2. Configure the BOLA trigger.

  3. Test the configuration of BOLA protection.

Configuring the trigger to identify the BOLA attacks

For the Wallarm node to identify the BOLA attacks:

  1. Open Wallarm Console → Triggers and proceed to the BOLA trigger setup.

  2. Set the conditions for defining requests as the BOLA attack:

    • The number of Requests from the same IP for a period of time.
    • URI that should be protected against the BOLA attacks and to which the specified number of requests should be sent. The value should be an API endpoint pointing to an object by its identifier since this endpoint type is potentially vulnerable to the BOLA attacks.

      To specify the PATH parameter identifying an object, use the symbol *, e.g.:*/financial_info

      URI can be configured via the URI constructor or advanced edit form in the trigger creation window.

    • (Optional) Application that should be protected against the BOLA attacks and to which the specified number of requests should be sent.

      If you use the same name for several domains, this filter is recommended to point to an application the domain in the URI filter is assigned for.

    • (Optional) One or more IPs the requests are sent from.

  3. Select trigger reactions:

    • Mark as BOLA. Requests received after the threshold exceedance will be marked as the BOLA attack and displayed in the Events section of Wallarm Console. Wallarm node will NOT block these malicious requests.
    • Denylist IP address and the period for IP address blocking to add IP addresses of malicious request sources to the denylist.

      The Wallarm node will block both legitimate and malicious requests (including the BOLA attacks) originating from the denylisted IP.

    • Graylist IP address and the period to graylist IP addresses of malicious request sources.

      The Wallarm node will block requests originating from the graylisted IPs only if requests contain input validation, the vpatch or custom attack signs.

      BOLA attack originating from graylisted IPs

      The BOLA attacks originating from graylisted IPs are not blocked.

  4. Save the trigger and wait for the Cloud and node synchronization completion (usually it takes 2-4 minutes).

Example of a trigger to detect and block BOLA attacks aimed at shop financial data (the API endpoint is{shop_id}/financial_info):

BOLA trigger

You can configure several triggers with different filters for BOLA protection.

Testing the configuration of BOLA protection

  1. Send the number of requests that exceeds the configured threshold to the protected URI. For example, 50 requests with different values of {shop_id} to the endpoint{shop_id}/financial_info:

    for (( i=0 ; $i<51 ; i++ )) ; do curl$i/financial_info ; done
  2. If the trigger reaction is Denylist IP address, open Wallarm Console → IP listsDenylist and check that the source IP address is blocked.

    If the trigger reaction is Graylist IP address, check the section IP listsGraylist of Wallarm Console.

  3. Open the section Events and check that requests are displayed in the list as the BOLA attack.

    BOLA attack in the UI

    The number of displayed requests corresponds to the number of requests sent after the trigger threshold was exceeded (more details on detecting behavioral attacks). If this number is higher than 5, request sampling is applied and request details are displayed only for the first 5 hits (more details on requests sampling).

    To search for the BOLA attacks, you can use the bola search tag. All filters are described in the instructions on search use.