> For the complete documentation index, see [llms.txt](https://docs.xygeni.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.xygeni.io/xygeni-products/api-security/api-security-user-interface-guide/risks-api-security.md). # API Security Risks The **Risks (API Security) page** can be accessed by selecting the **API Security** option in the [**Risks**](/xygeni-products/application-security-posture-management-aspm/all-risks.md) tab. This tab presents the full set of findings raised by the API Security scanner, organised so flaws can be triaged quickly. {% hint style="info" %} Xygeni's API Security findings come from the bundled [API Security Scanner](/xygeni-products/api-security/api-security-scanner.md). API Security findings are automatically correlated with SAST and DAST findings on the same endpoint in the [Xygeni ASPM Risk Graph](/xygeni-products/application-security-posture-management-aspm.md), so a single broken endpoint shows the *static* code-level evidence, the *dynamic* runtime evidence, and the *shape* evidence side by side. {% endhint %} ## Inventory Each API Security scan produces an **endpoint inventory** in addition to the flaw list. The inventory is the structural backbone of the report and is exposed on its own panel: * **Services** — deployable applications or microservices discovered in the project (typically one per detected framework manifest). * **Modules** — controllers, resources, or routers that group related endpoints under a common path prefix. * **Endpoints** — individual callable operations. Each endpoint carries its HTTP method, path, authentication requirement, parameter list, and handler location (source file + line). * **Data Objects** — request and response shapes (DTOs / schemas / structs) referenced by endpoints. Fields are individually tagged when classified as PII / PCI / PHI / credential / crypto by the sensitivity classifier. The inventory is also written even in **inventory-only** mode (`--discovery-only`) — see the [API Security Scanner](/xygeni-products/api-security/api-security-scanner.md) page. ## Finding Details Each API Security finding (an *ApiFlaw*) includes the following information: * **Detector ID**: the rule that produced the finding (for example, `broken_object_level_authorization`, `excessive_data_exposure_java`, `unauthenticated_endpoint`). * **Severity**: the risk level — `critical`, `high`, `medium`, `low`, or `info`. Several detectors are *tiered* — for example, `cors_misconfiguration` produces HIGH when wildcard origin is combined with credentials, LOW for wildcard alone. * **Confidence**: how confident the scanner is in the finding — `low`, `medium`, `high`. Per-language detectors that walk the handler AST raise confidence to `high` when explicit evidence is found. * **Endpoint**: the affected endpoint — method, path, service, module, and handler source location. * **OWASP API Top 10 (2023)**: the matching entry — `API1:2023` through `API10:2023` — surfaced as a tag for filtering and as a column on the listing. * **CWE**: the associated Common Weakness Enumeration identifier(s). * **Compliance mappings**: where applicable, findings carry tags for **GDPR**, **PCI-DSS**, and **NIST SP 800-53** controls, so API Security results can be traced directly to compliance requirements. * **Evidence**: the concrete signal that produced the finding — for example, the request-body field name that triggered a Mass Assignment finding, the response DTO field tagged PII that produced an Excessive Data Exposure finding, or the OpenAPI operation that has no matching handler for an Orphan Spec finding. * **Remediation**: per-detector guidance, with framework-specific examples linked from the [API Security Detectors](/xygeni-products/api-security/api-security-detectors.md) catalog. ## Composite Findings The API Security scanner runs a **flaw correlator** that emits a composite finding when two related signals coincide on the same endpoint. The most important is: * **`pii_leak_in_unauthenticated_endpoint`** — emitted at **CRITICAL** severity when an endpoint is flagged both `pii_leak_in_response` *and* `unauthenticated_endpoint`. A single, prioritised line item replaces the two individual findings on the listing while preserving full traceability back to its component flaws. ## Severity Levels API Security findings are mapped to five severity levels: | Severity | Description | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Critical** | Directly exploitable, high-impact (composite findings such as PII leak on an unauthenticated endpoint, JWT `alg: none` accepted, signature verification disabled). | | **High** | Likely-real defect with confirmed evidence — BOLA / BFLA with no ownership / role check, PII / PCI / PHI in response, mass assignment of privilege fields, wildcard CORS with credentials. | | **Medium** | Plausible defect that needs review (typically MEDIUM-tier confidence variants of HIGH detectors — e.g. excessive data exposure on a field referenced in the request). | | **Low** | Defence-in-depth issues with limited direct impact — wildcard CORS without credentials, rate-limit absence (advisory; infrastructure-level limits are not visible to static analysis), SSRF-shaped parameter alone. | | **Info** | Informational findings flagged for context (typically suppressed candidates and inventory annotations). | ## Filtering and Triage Beyond the standard severity / confidence filters available across all Xygeni scans, the API Security view offers two API-specific facets: * **OWASP API Top 10 (2023)** — filter findings by `API1` through `API10`. Useful when working a single risk category across the codebase. * **Authentication state** — restrict the listing to endpoints flagged as *unauthenticated* (independently of any flaw they may carry), or conversely to endpoints that *do* require authentication. These compose with the global filters (severity, confidence, kind, project, repository, branch, tags), so a typical triage view — "all CRITICAL or HIGH API1 / API3 findings on `main` for the production projects" — is one click away. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.xygeni.io/xygeni-products/api-security/api-security-user-interface-guide/risks-api-security.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.