[API Shield] Update BOLA vulnerability detections doc (#22178)

* feedback fixes

* fix enumeration description

* pcx feedback

Author: patriciasantaana

public/__redirects

@@ -199,6 +199,7 @@
 
 # api-shield
 /api-shield/security/sequential-abuse-detection/ /api-shield/security/sequence-analytics/ 301
+/api-shield/security/bola-attack-detection/ /api-shield/security/bola-vulnerability-detection/ 301
 
 #autorag
 /autorag/usage/recipes/ /autorag/how-to/ 301

src/content/docs/api-shield/security/bola-attack-detection.mdx renamed to src/content/docs/api-shield/security/bola-vulnerability-detection.mdx

@@ -1,7 +1,7 @@
 ---
 pcx_content_type: concept
 type: overview
-title: Broken Object Level Authorization attack detection
+title: Broken Object Level Authorization vulnerability detection
 sidebar:
   badge:
     text: Beta
@@ -11,21 +11,21 @@ sidebar:
 
 import { Badge } from "~/components";
 
-A Broken Object Level Authorization (BOLA) attack is where an application or API fails to properly verify if a user has permission to access specific private data.
+A Broken Object Level Authorization (BOLA) vulnerability is where an application or API fails to properly verify if a user has permission to access specific data.
 
-Bugs in the application or API allow attackers to bypass authorization checks and access sensitive information by manipulating and iterating through object identifiers.
+Bugs in the application or API allow attackers to bypass authorization checks and access potentially sensitive information by manipulating and iterating through object identifiers.
 
 Vulnerabilities can occur at any time, including in the original application's deployment. However, changes or upgrades to authentication and authorization policies can also introduce these bugs.
 
-BOLA attacks are as dangerous as account takeover. A successful BOLA attack allows the attacker to access or change data that they should not have ownership over.
+BOLA vulnerabilities are as dangerous as an account takeover. Successfully exploiting a BOLA vulnerability allows the attacker to access or change data that they should not have ownership over.
 
-Cloudflare labels endpoints with BOLA risk when we detect two distinct signals common with BOLA attacks: **Parameter pollution** and **Enumeration**.
+Cloudflare labels endpoints with BOLA risk when we detect two distinct signals common with attacks exploiting BOLA: **Parameter pollution** and **Enumeration**.
 
-- **Parameter pollution**: Cloudflare detects anomalies where one or more successful requests containing a value in an expected path, query string, header, or body parameter have that value duplicated in an unexpected, similar location. 
+- **Parameter pollution**: Cloudflare detects anomalies where one or more successful requests containing a value in an expected path, query string or header have that value duplicated in an unexpected, similar location. 
 
     This behavior may be indicative of attackers trying to confuse the API’s authorization system and bypass security controls.
 
-- **Enumeration**: Cloudflare detects anomalies where one or more sessions makes successful requests to any one API endpoint that changes variable values trying to get information from the API. 
+- **Enumeration**: Cloudflare continually profiles all sessions on a per-endpoint basis and detects anomalous sessions that successfully request many unique data points from an API endpoint against what is normal.
 
 :::note
 Sessions that have more random behavior or repetition have a higher chance of triggering an alert. 
@@ -37,17 +37,19 @@ The BOLA enumeration label requires an endpoint to have seen at least 10,000 ses
 
 ### Parameter pollution attack
 
-**Endpoint**: `GET /api/v1/credit-cards/{cardId}`
+**Endpoint**: `GET /api/v1/orders/{orderId}`
 
-- **Normal behavior**: `cardId` is sent in a path variable.
-- **Attacker behavior**:`cardId` is also sent as a query parameter, which triggers old and undocumented code that looks for cards in the query parameter that lacks the authorization check: `GET /api/v1/credit-cards/{cardId}?cardId=12345`.
+- **Normal behavior**: `orderId` sent in a path variable like `GET /api/v1/orders/12345`
+- **Attacker behavior**: `orderId` is also sent as a query parameter, triggering old, undocumented code that looks for orders in the query parameter and happens to lack an authorization check: `GET /api/v1/orders/12345?orderId=67890`
+- **Result**: By passing in a bogus order or an order that the attacker owns (`12345`), they are able to trigger the old, undocumented code and access an order that they do not own (`67890`)
 
 ### BOLA enumeration attack
 
-**Endpoint**: `GET /api/v1/credit-cards/{cardId}`
+**Endpoint**: `GET /api/v1/users/{userId}/credit-cards`
 
-- **Normal behavior**: Users request one to two credit cards per session.
-- **Attack behavior**: Attackers request hundreds of credit card values per session. 
+- **Normal behavior**: Users request credit cards using only their own `userId`.
+- **Attack behavior**: Attackers request hundreds of `userId` values per session by brute-force iterating through `userIds` found via other methods.
+- **Result**: If the authorization policy is broken for this endpoint, the attacker gains credit card information on every user account they request it for.
 
 ## Process