# F5XC API path explainer

> Paste the OpenAPI / Swagger spec you import into (or download from) F5XC API Protection and it lists every path and operation with its method, parameters, request body, responses, and authentication.

- Tool: https://ronutz.com/en/tools/f5xc-api-path-explainer
- Family: Networking

---

## What it does

This tool explains an OpenAPI or Swagger specification - the exact artifact F5 Distributed Cloud (XC) API Protection works with. XC imports an OpenAPI spec (version 2.0 or 3.0.x) to build its API inventory and enforce a positive security model, and XC API Discovery generates a downloadable Swagger JSON you can edit and re-import. Paste that spec and this tool lists every path and operation with its method, parameters, request body, responses, and whether it requires authentication. It runs entirely in your browser.

## The inventory it builds

For each path, the tool walks every operation - GET, POST, PUT, PATCH, DELETE, and the rest - and reports the same details XC uses to define valid behavior: the parameters (name, location, and whether they are required), the request body content types, the response codes, and the security schemes that apply. It resolves local $ref parameters within the document, so a parameter defined once and referenced across operations is shown in full at each use. The summary at the top counts the paths, the operations, and how many are unauthenticated, object-level, or deprecated.

## Authentication, resolved correctly

Whether an operation requires authentication is not always stated on the operation itself. OpenAPI lets you set a global security requirement and override it per operation - and an operation with an empty security list is explicitly public, even if the API has a global requirement. The tool resolves this the way the spec defines it: an operation uses its own security if present, otherwise the global one, and an empty list means no authentication. That is why an operation can show as unauthenticated even in an API that mostly requires a token.

## The flags, and why they map to OWASP

The tool flags two things that matter for API security. An operation with no effective security is a Broken Authentication risk - it is reachable without credentials. An endpoint with a path parameter, like /orders/{id}, is an object-level access point and the classic surface for Broken Object Level Authorization, the top item on the OWASP API Security Top 10: the API must check that the caller is allowed to touch that specific object, not just that they are logged in. These are prompts to verify your authorization design, not proof of a vulnerability - but they are exactly the endpoints worth checking first.

## Standards and references

- [F5 Distributed Cloud: Import OpenAPI Specification to Define API Definition (supported versions: OpenAPI 2.0 and 3.0.x)](https://docs.cloud.f5.com/docs-v2/web-app-and-api-protection/how-to/adv-security/import-openapi-spec) - XC imports OpenAPI 2.0 (Swagger) and 3.0.x specs to build the API inventory (endpoints + methods) and drive OpenAPI Validation as a positive security model
- [F5 Distributed Cloud: Enable API Endpoint Discovery and Schema Learning (downloaded Swagger file is JSON)](https://docs.cloud.f5.com/docs-v2/web-app-and-api-protection/how-to/app-security/apiep-discovery-control) - XC API Discovery learns schemas from traffic and generates a downloadable Swagger JSON that can be edited and re-imported - the same artifact this tool reads
- [OpenAPI Specification (paths, operations, parameters, requestBody, responses, security, components)](https://swagger.io/specification/) - the OpenAPI 2.0/3.x document structure this tool parses, including $ref resolution and security requirement semantics
- [OWASP API Security Top 10 (Broken Object Level Authorization, Broken Authentication, Improper Assets Management)](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) - the risk framing for the flags: unauthenticated operations (Broken Authentication) and object-level path-parameter endpoints (Broken Object Level Authorization)

## Related reading

- [The OpenAPI Spec as XC's API Inventory: Paths, Auth, and the Shadow](https://ronutz.com/en/learn/f5xc-openapi-and-api-inventory.md): XC API Protection is a positive security model built from an OpenAPI spec (2.0 or 3.0.x): the spec's paths and methods become the API inventory that drives validation, and undocumented endpoints are Shadow APIs. This covers why the spec is the source of truth, how API Discovery generates one from traffic, how to resolve authentication correctly (global vs per-operation, and the empty-list public override), and why path-parameter endpoints are the Broken Object Level Authorization surface.