API Security Risks

The Risks (API Security) page can be accessed by selecting the API Security option in the Risks tab. This tab presents the full set of findings raised by the API Security scanner, organised so flaws can be triaged quickly.

Xygeni's API Security findings come from the bundled API Security Scanner. API Security findings are automatically correlated with SAST and DAST findings on the same endpoint in the Xygeni ASPM Risk Graph, so a single broken endpoint shows the static code-level evidence, the dynamic runtime evidence, and the shape evidence side by side.

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 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 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.