Every pull request that adds or changes an endpoint changes your API attack surface. Most API security tools don’t notice until that endpoint is live and already taking traffic. By then, the fix is no longer a one-line change in a code review, i;t’s an incident response conversation.
API security is the practice of finding and closing the risks in how an application exposes its endpoints: who can call them, what data they return, and whether they do what the documentation says they do.
Most of the tooling built for this problem tests the API at runtime, from the outside, the same way an attacker would. That approach works, but it only works after the API is deployed. Xygeni takes the earlier path: it reads your source code and your API specification before a single request ever hits the endpoint.
The Four Ways to Test an API, and What Each One Answers
Most mature programs run more than one of these:
- Static testing analyzes source code and API specifications before deployment. It answers “what did we just expose?” This is the approach this article focuses on.
- Dynamic testing (DAST) sends real traffic at a running API and observes how it responds. It answers “what is actually reachable and exploitable right now?”
- Fuzzing throws malformed or unexpected input at endpoints to surface crashes and edge-case failures. It answers “what breaks under input we didn’t anticipate?”
- Manual penetration testing adds human judgment to find logic flaws automated tools miss. It answers “what would a smart attacker chain together?”
None of these replace the others. They answer different questions at different points in the lifecycle, and the gap most programs have is the first one.
Why Most API Security Tools See the Risk Too Late
Runtime API security testing sends traffic at a live application and watches how it responds. It’s a legitimate and necessary layer. It is also, by construction, a lagging indicator: an endpoint has to exist, be deployed, and be reachable before a runtime scanner can say anything about it. Whatever it finds was already exposed for however long it took the scan to run.
There’s a second gap underneath that timing problem. Runtime tools can only test what they know exists. If an endpoint was never documented, or the OpenAPI spec drifted out of date the moment someone shipped a new route, a runtime scanner has no way to know it’s there. It tests the map, not the territory.
Static API security testing closes both gaps by moving the check to where the endpoint is defined: your code and your API specification, before deployment. The same pull request that introduces an endpoint is the pull request that surfaces its risk.
What Static API Security Actually Means
Xygeni builds your API inventory from two sources: your application’s source code and your API specifications, including OpenAPI and Swagger.
A spec-only inventory shows the endpoints someone remembered to document. A code-only inventory shows what exists but not necessarily how it was meant to be used. Reading both gives you the complete picture: the endpoints your teams documented, and the ones nobody did.
That inventory is the foundation everything else builds on:
- Total APIs discovered, and assets at risk measured against a baseline
- Endpoints broken down by HTTP method
- Issues grouped by service
- Every endpoint with its method, path, service, module, authentication state and risk score
Your engineering leads see the shape of your API surface without opening a single ticket.
Every endpoint Xygeni found, with its method, authentication state and risk score, built from code and specification together.
Production note Crop the AI Triage panel from any API Security screenshot.
Mapped to the OWASP API Security Top 10
Findings speak the framework your security teams and your auditors already use. Xygeni detects risk across the OWASP API Security Top 10 (2023):
One category is deliberately absent. API6, Unrestricted Access to Sensitive Business Flows, requires understanding what a business process is supposed to allow, and no static analyzer detects that credibly. Any vendor claiming otherwise is selling you a checkbox. That one stays with your threat modeling and your penetration testers.
Not Every Finding Is Equal: Data Sensitivity and Toxic Combinations
A flat list of findings treats an unauthenticated health-check endpoint the same as an unauthenticated endpoint that returns customer records. Those are not the same problem, and a prioritization model that scores them identically trains your teams to ignore the list.
Xygeni classifies the data each endpoint handles, flagging PII, PCI and PHI in request parameters and in responses, and pairs that with the endpoint’s authentication state.
It also correlates findings that land on the same endpoint and raises severity when they compound. A PII leak in a response is a serious finding on its own. The same leak on an endpoint that requires no authentication is critical, and the platform scores it that way instead of leaving the connection for someone to notice manually.
Zombie and Orphan Endpoints: The Drift Between Code and Spec
Because Xygeni reads your code and your API specification side by side, it sees where they disagree. That drift shows up as three recognizable patterns:
- Undocumented endpoints. They live in code and were never added to the spec.
- Zombie endpoints. They are marked as deprecated or retired, and they are still reachable.
- Orphan endpoints. Nobody on the current team owns them.
None of these show up in a spec-only inventory, because the spec is exactly what’s missing them.
Evidence You Can Act On, Not a Ticket to Investigate
Every finding points at the exact handler responsible: the file, the class, the method, and the specific line that introduced the flaw, with the offending code rendered alongside it. Each one also carries its severity, its OWASP API Security Top 10 category, its CWE, the endpoint’s authentication state, and the sensitivity classification of the data involved.
A finding that just names an endpoint sends a developer hunting through the codebase before they can even start fixing anything. A finding that names the line puts them at the fix immediately.
Findings export as JSON, CSV, Markdown and SARIF 2.1.0, so they land in the tools your teams already work in.
The handler, the line, and the code that introduced the exposure. Not a ticket to investigate.
Why This Lives in One Platform, Not Another Console
Xygeni runs API Security alongside SAST, SCA, Secrets Security, IaC and DAST inside a single platform, correlated through ASPM, instead of shipping it as a separate tool with its own login and its own backlog.
That matters because static findings and runtime findings answer different questions about the same endpoint, and they are more useful together than apart. Static tells you an endpoint is risky before it ships. DAST confirms what’s actually reachable and exploitable once it’s running.
Split that across two consoles and correlated risk becomes two unrelated backlogs. Nobody reconciles them, and the endpoint that is both undocumented and unauthenticated sits in neither queue.
See your real API attack surface. API Security is available as an Enterprise add-on to the Xygeni platform, and a scan runs against your own repositories inside your own infrastructure.
FAQ
Can it tell which endpoints handle sensitive data?
Yes. Xygeni flags PII, PCI and PHI in endpoint parameters and responses, and uses that classification to rank findings by real exposure.
Can it run on every pull request?
Yes. Incremental scanning analyzes only the endpoints that changed, and the manifest it produces can focus a subsequent DAST scan on those same endpoints, so static and runtime testing stay aligned to what actually moved.
Does my code leave my environment?
No. Scans run in your own infrastructure. Only results are uploaded, protected in transit and at rest.
How do I get API Security?
API Security is available as an Enterprise add-on. Request a PoC and it will be scoped with you.
