F5 Distributed Cloud Runtime API Security Detections

Purpose and scope

F5 Distributed Cloud Web App & API Protection (WAAP) provides runtime, traffic-based behavioral detections for API Security. These detections help identify suspicious API behavior, authorization abuse, authentication weaknesses, and potential exploitation attempts based on observed API traffic and API context.

The OWASP API Security Top 10 defines a taxonomy of common API risks. These risks are addressed through multiple API Security capabilities, including behavioral detections, API posture analysis, API definitions, schema and OpenAPI-based validation, configuration checks, and policy-based protections.

This guide focuses on the detection layer. Broader OWASP API Top 10 coverage should be evaluated across the full API Security capability set, not only through runtime detections.

---

How Runtime API detections work

Runtime API detections are generated by analyzing API traffic and API context through the detection pipeline. Depending on the detection type, F5 may use observed traffic behavior, identity signals, API definitions, discovered or approved API inventory, uploaded OpenAPI specifications, and configured API protection policies.

The system does not rely on a single detection method. Some detections are primarily behavior-driven, while others use API definitions or schema boundaries as the source of expected API behavior. For example, BOLA and enumeration rely heavily on observed access patterns and identity-to-resource correlation, while BOPLA and some authentication-related detections may rely more directly on API definitions, schema structure, and expected authentication requirements.

The detection pipeline moves through the following stages:

1. Observe API traffic: F5 analyzes API requests and responses, endpoints, methods, parameters, object identifiers, authentication signals, identity information, and request patterns. These signals provide the runtime view of how APIs are actually used.
2. Build API context: The platform builds API context from API Discovery, approved discovered APIs, uploaded OpenAPI specifications, and schema information. This context helps define expected endpoints, request structures, object properties, authentication requirements, and policy boundaries.
3. Correlate runtime and definition-based signals: The detection pipeline correlates runtime traffic with API context. This allows F5 to identify whether a request is suspicious because it deviates from learned access patterns, violates expected schema boundaries, uses unexpected properties, accesses private resources, or conflicts with expected authentication behavior.
4. Detect suspicious behavior and generate a finding: Detected activity is surfaced as security incidents or findings with supporting context, allowing customers to investigate the behavior and apply the appropriate mitigation controls.

---

Learning period and detection confidence

Some runtime API detections require a learning period before the platform can reliably identify suspicious behavior. The required learning period differs by detection type.

Detections based on API definitions, schemas, or explicit configuration signals may be generated earlier. Behavioral detections, such as BOLA or enumeration-related incidents, typically require sufficient traffic volume and multiple discovery or analysis cycles before the platform can classify private resources, learn user-to-resource access patterns, and generate incidents with higher confidence.

For example, private resource classification may require time to observe enough unique users, resource identifiers, and access patterns. This learning process helps improve detection accuracy and reduce false positives.

The platform continuously refines its detection confidence as more API traffic is observed and analyzed.

---

Detection domains

The detections described in this guide are grouped into the following domains:

Detection domain	What it identifies	Examples
Object-centric authorization abuse	Suspicious access to private objects, object identifiers, or object properties.	BOLA, BOPLA, enumeration behavior
Function and action abuse	Unauthorized use of sensitive functions, methods, or actions.	BFLA, method-based and action-based misuse
Authentication weaknesses	Missing, weak, or misconfigured authentication behavior.	Broken Authentication, weak authentication signals

---

BOLA — Broken Object Level Authorization

BOLA occurs when an API allows a user to access an object instance that should belong to another user, tenant, account, or identity. The request may look syntactically valid, but the abuse becomes visible when the requested object is correlated with the requesting identity.

What F5 observes: F5 observes user identity signals, private resource identifiers, endpoint behavior, request parameters, and repeated access patterns across API traffic. Private resource identifiers may include account IDs, vehicle IDs, order IDs, tenant IDs, or similar object references.

How detection works: The platform extracts resource identifiers from API requests and correlates them with identity signals such as JWT claims. Over time, the detection pipeline learns expected identity-to-resource access patterns. Suspicious activity may be identified when a user accesses a private resource outside the expected ownership or authorization pattern. Enumeration behavior can also be used as a supporting signal when an actor systematically iterates over private resource identifiers in order to discover or access resources outside the expected scope.

Customer outcome: Customers receive a BOLA-related security incident with context about the affected endpoint, identity signals, observed resource identifiers, and suspicious access pattern. Customers can investigate the behavior and apply mitigation controls such as API protection rules, user or IP blocking, rate limits, or stricter authorization enforcement in the application.

---

BOPLA — Broken Object Property Level Authorization

BOPLA occurs when an API fails to enforce authorization at the property level of an object. A user may be allowed to access or modify the object, but should not be allowed to access or manipulate specific sensitive properties within that object.

What F5 observes: F5 analyzes request parameters, object properties, API definitions, schema structure, and identity signals. The focus is on whether the request includes properties or parameters that are not expected, not allowed, or sensitive for the specific API operation.

How detection works: BOPLA detection uses API definitions, schema information, and observed request structure to identify property-level authorization issues. For example, if the API definition or schema establishes the expected properties for a request, the detection pipeline can identify unexpected or sensitive properties that may indicate unauthorized property-level access or manipulation.

Customer outcome: Customers receive a BOPLA-related incident with context about the affected endpoint and observed property or parameter behavior. Customers can investigate property-level authorization gaps and apply schema validation, request-body validation, or policy-based protections where appropriate. Mitigation may also include JWT claim-based policy logic. For example, a policy can allow a specific property only when a defined JWT claim has an expected value, and block or restrict the request when the claim does not match the required authorization condition.

---

BFLA — Broken Function Level Authorization

BFLA occurs when an API allows a user to perform a function or action that should be restricted to a different privilege level. Unlike BOLA, which focuses on which object is accessed, BFLA focuses on which operation or function the user is allowed to perform.

What F5 observes: F5 observes API-accessible functions and actions, HTTP methods, endpoint usage, identity signals, JWT claims, and authorization-related request context.

How detection works: The detection pipeline maps API-accessible functions and actions and evaluates whether observed access aligns with the expected authorization model. Unauthorized or unexpected function execution attempts may be reported as BFLA security incidents.

Customer outcome: Customers receive a BFLA-related incident with context about the affected endpoint, function or action, identity signals, and suspicious authorization pattern. Customers can investigate the authorization gap and apply mitigation controls such as API protection rules, method restrictions, role-based policy controls, or JWT claim-based enforcement. For example, a policy can allow access to a sensitive function only when a specific JWT claim or role value is present, and block or restrict the request when the claim does not satisfy the required condition.

---

Broken Authentication Detection

Broken Authentication occurs when authentication mechanisms are weak, missing, misconfigured, or inconsistently enforced. These weaknesses can allow attackers to impersonate legitimate users or access protected APIs without the expected authentication controls.

What F5 observes: F5 uses API Discovery, approved API inventory, uploaded OpenAPI specifications, endpoint behavior, and authentication signals to understand expected authentication requirements and observed authentication behavior.

How detection works: The platform identifies authentication-related risks by comparing expected authentication behavior with observed traffic. This may include endpoints that appear to be protected but are accessed without expected authentication, endpoints with inconsistent authentication behavior, or weak authentication signals that indicate misconfiguration or enforcement gaps.

Customer outcome: Customers receive a vulnerability finding or security incident, depending on the detected issue, with context about the affected endpoint and authentication behavior. Customers can use this information to investigate authentication gaps and apply appropriate enforcement, configuration changes, or API protection controls.

---

Prerequisites and operating requirements

The detection capabilities described in this guide require an F5 Distributed Cloud account and the appropriate subscription or entitlement for the relevant API Security capabilities.

See the following:

• Customers should enable the API Discovery mechanisms required to build API inventory and API context.
• API definitions may be created through discovery and approval workflows or provided through uploaded OpenAPI specifications, depending on the use case.
• Mitigation workflows may require API Protection or policy-based controls to be enabled and available for the relevant load balancer or application context.
• Some detections may require sufficient traffic volume and learning time, as described in the Learning Period and Detection Confidence section.

---

Concepts

• API Discovery
• API Protection
• OWASP API Security Top 10

How-to guides

• Setting Up API Discovery
• Setting Up API Protection
• Automate API Security Testing

---