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

# API Security

### **Overview**

Xygeni's **API Security** scanner discovers the API surface of an application — its services, endpoints, parameters, request and response shapes — and analyses it for the **OWASP API Security Top 10 (2023)** risks. It is a **static** analysis: the scanner reads source code and API descriptors and produces an inventory and a set of flaws, with no live traffic against a running application.

API Security pairs naturally with the rest of the Xygeni platform. The **inventory** it produces is the join key that links **static** handler code (SAST findings) to **dynamic** endpoint behaviour (DAST findings) in the Risk Graph, giving security and engineering teams a single, deduplicated view of "what does my API expose, and which findings touch it?".

### **Protect APIs from Design and Implementation Flaws**

APIs are the primary integration surface of modern applications — and the primary attack surface. Xygeni's API Security scanner is built to detect:

* **Broken authentication and authorization** — unauthenticated endpoints (API2), missing role checks on admin-shaped routes (API5), missing ownership checks on object-by-id endpoints (API1 / IDOR).
* **Sensitive data exposure** — PII / PCI / PHI fields reaching the wire (API3 / API10), over-fetched response shapes, sensitive parameters on unauthenticated endpoints (API2 + API3).
* **Mass assignment** — request bodies that bind to privileged attributes (API3 write side).
* **Configuration risks** — permissive CORS (API8), JWT misconfiguration (API2), absence of rate limiting (API4), Server-Side Request Forgery (API7).
* **Inventory drift** — endpoints in code that are missing from the OpenAPI / Swagger spec, and operations declared in the spec with no corresponding handler (API9 — *shadow* and *orphan* APIs).

Each flaw is mapped to its **OWASP API Top 10 (2023)** entry as the primary taxonomy, and to one or more **CWE** identifiers as the secondary taxonomy. Findings are produced with the same metadata, evidence, and severity model as the other Xygeni scans, so they integrate uniformly into dashboards, gates, and compliance reports.

### Supported Frameworks

Endpoint discovery is framework-aware. The scanner ships with detectors for the most-used API frameworks across six languages:

| Language    | Frameworks                                                |
| ----------- | --------------------------------------------------------- |
| **Java**    | Spring MVC / Spring Boot, JAX-RS                          |
| **C#**      | ASP.NET Core (Controllers and Minimal APIs)               |
| **Python**  | FastAPI, Flask, Django / Django REST Framework, Connexion |
| **JS / TS** | Express, NestJS, Koa, Fastify, Hono                       |
| **Go**      | net/http, Gin, Echo, Chi, Fiber, gorilla/mux              |
| **PHP**     | Laravel, Symfony, Slim                                    |
| **Any**     | OpenAPI 3.x and Swagger 2.x specifications (YAML or JSON) |

Before each scan, a lightweight **framework autodiscovery** pre-pass inspects the project's dependency manifests (`pom.xml`, `build.gradle`, `package.json`, `requirements.txt`, `pyproject.toml`, `*.csproj`, etc.) to determine which frameworks are present, and loads only the relevant detectors. This keeps scan time low and avoids cross-framework false positives.

### Scan Modes

The scanner supports two modes selected by a single CLI flag:

| Mode               | What it does                                                                                                                                              |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Full scan**      | Discovery + flaw detection. Inventory plus all enabled OWASP API risk detectors. This is the default.                                                     |
| **Inventory-only** | Discovery only (`--discovery-only`). No flaw detection. Useful when feeding the endpoint inventory to SAST / DAST correlators, or for catalog generation. |

Even in inventory-only mode, the scanner runs **sensitivity classification** — endpoints, parameters, and DTO fields carry their PII / PCI / PHI / credential tags either way, since SAST and DAST correlators rely on those tags to score risk.

For more information regarding API Security, refer to these sections:

* [API Security User Interface Guide](/xygeni-products/api-security/api-security-user-interface-guide.md)
  * [Risks (API Security)](/xygeni-products/api-security/api-security-user-interface-guide/risks-api-security.md)
* [API Security Scanner](/xygeni-products/api-security/api-security-scanner.md)
  * [API Security Scanner Configuration](/xygeni-products/api-security/api-security-scanner/api-security-scanner-configuration.md)
* [API Security Detectors](/xygeni-products/api-security/api-security-detectors.md)


---

# 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.md?ask=<question>&goal=<endgoal>
```

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