One queue
API findings sit beside SAST, DAST and dependency findings, so a team sees every issue on a service in one place, not in a separate API console.
API security
Understand your APIs.
Investigate the exposure.
Connect API specifications, discovered endpoints and security findings. Give your team a shared view of the API surface and its evidence.
API contract
Request method
Endpoint path
Authentication contract
Investigation context
01 / Inventory
Know the interface under review.
- Specification source
- Endpoint identity
Start with the API specification and the endpoint it describes.
02 / Examine
Understand the API finding.
- Security definition
- Finding context
Inspect the relevant endpoint, security definition and supporting evidence.
03 / Coordinate change
Give the API owner a precise target.
- API owner
- Contract revision
Keep contract and endpoint references with the remediation discussion.
OWASP
API Security Top 10
Checked from the specification.
2 · 3
Swagger and OpenAPI
Operation and global security resolved.
Code
Route auth check
Flask, FastAPI, Express, Spring.
Catalogue
Shadow and zombie
With drift and change history.
The category
What is API security?
APIs fail differently from web pages. The common breaches are not exotic injections but authorisation mistakes: an endpoint that returns another customer's order because it trusts the identifier in the path, or an admin operation that any authenticated user can call. The OWASP API Security Top 10 names these risks. Testing for them needs two kinds of knowledge: what each API promises in its specification, and what the code behind it actually enforces. Inventory is the other half, because an API nobody knows about is an API nobody tests.
SecurityVault reads both sides and compares them. The specification says what each operation should require; the route guards in Flask, FastAPI, Express or Spring show the authentication controls the analyser recognises; and supplied traffic can reveal undocumented endpoints. Findings join application and cloud context with remediation deadlines. Inventory coverage depends on the specifications, source and observations you provide; authorisation behaviour still requires contextual testing.
Specification
Read the authentication requirement for an operation.
Route guard
Inspect the controls recognised in the source.
Observed endpoint
Review supplied traffic for undocumented operations.
Contract, implementation and observations contribute different evidence.
How SecurityVault does it
How does SecurityVault test APIs?
Specification
Swagger 2 and OpenAPI 3 documents are parsed into endpoints with their methods, parameters and security requirements, inheriting global security where an operation declares none. The analysis flags object-level and function-level authorisation gaps, weak authentication schemes, mass-assignment exposure, unbounded payloads, server-side request forgery surfaces, misconfiguration, deprecated operations and unsafe third-party consumption.
Source code
The route authentication check reads Flask, FastAPI, Express and Spring routes and the guards on them, and reports sensitive routes that are reachable without one, whether or not they appear in a specification.
Catalogue
Every discovered endpoint enters an API catalogue with its change history. Conformance views compare the specification with what is observed, and drift shows when the two part ways.
Shadow and zombie
Access logs you send are matched against the catalogue to surface shadow APIs that serve traffic with no specification. Deprecated endpoints that are still reachable are flagged as zombie APIs every day.
Runtime
A runtime inspection API checks individual requests against the API's specification and your runtime policies, recording alerts with their outcome. Opt-in active probing tests live endpoints under a per-configuration request-rate limit, and any API finding can be retested on demand.
After the scan
Where do API security findings go?
Into the same findings model as code, dependency, image and cloud findings, with a remediation deadline from your SLA policy.
01
02
Raised by context
Review source findings alongside route authentication context to understand potential exposure. Confirm actual authorisation behaviour before concluding that a route is exploitable.
03
Deadlines
Findings receive remediation deadlines from your severity-based SLA policy, tracked in remediation and SLA operations alongside every other finding.
Evidence
Can I show an auditor which APIs exist and how they are tested?
Yes. The catalogue is the inventory, with the change history of every endpoint, and any finding can be retested on demand to show the fix holds. API findings are recorded as evidence when controls are evaluated, and the framework cross-walk maps them to the system-monitoring controls in your audit. See continuous compliance; release decisions sit with deployment gates.
API catalogue
Document the operations known to the inventory.
Test coverage
Attach the analysis and testing evidence available.
Control review
Expose missing coverage when evaluating the controls.
The inventory and test record support the review together.
FAQ
Frequently asked questions about API security
- Which OWASP API Security Top 10 risks does SecurityVault check?
- Checks flag specification and source-code indicators related to authentication, authorisation, resource limits, SSRF, configuration, inventory and third-party consumption. These are investigation leads, not proof that every OWASP category is covered. Object-level permissions and business-logic abuse require testing with appropriate identities and application context.
- What is a shadow API, and how is one found?
- A shadow API is an endpoint that serves traffic but appears in no specification. SecurityVault compares the access logs you send it against the API catalogue; any path that answers requests without a documented operation is flagged as shadow.
- What is a zombie API?
- An endpoint that is deprecated or no longer maintained but still reachable. SecurityVault flags zombie APIs daily from the catalogue, so a version you retired on paper but not in production is visible.
- Does SecurityVault send traffic to my APIs?
- Only if you choose to. Specification and source-code analysis need no traffic at all. Active probing is opt-in per scan configuration, with its own rate limit.
- Which frameworks does the route authentication check understand?
- Flask, FastAPI, Express and Spring. The check reads route definitions and their guards (decorators, dependencies, middleware and annotations) and reports sensitive routes that have none.
API testing works best with its neighbours: DAST probes the running application, SAST follows input from a route into the code behind it, attack surface management finds internet-facing hosts serving APIs, and threat modeling records which API threats matter most. Built for AppSec teams and security engineers. Glossary: API, API route, endpoint. See how it fits together on the ASPM platform page.
From the blog
Build an inventory you can investigate
- SSRF prevention: review a webhook delivery workerReview SSRF prevention in webhook workers with destination controls, redirect handling, isolated tests and evidence for release decisions.
- API authorisation: test your tenant boundariesBuild API authorisation tests around identity, tenant, object and action, using controlled fixtures to verify both allowed operations and denied access.
- API inventory: find undocumented endpoints safelyBuild an API inventory from specifications, source routes and deployment evidence, then assign ownership and review undocumented or retired endpoints.
- Authenticated DAST: prove what your scan reachedCheck authenticated DAST coverage with session verification, role-specific routes and a reproducible test record before trusting a quiet scan report.
See it on your stack
Bring one API specification.
One OpenAPI document and one repository, and the authorisation gaps between what the spec promises and what the code enforces.