The gap between documented and served endpoints
In every assessment we run, the served API surface exceeds the documented one — typically by 20% to 60%. The excess comes from deprecated versions kept alive for a single integration, internal endpoints exposed through a shared gateway, debug routes promoted with the build, and partner-specific paths created outside the platform team.
Undocumented endpoints are not merely unmonitored. They are usually the endpoints without rate limiting, without object-level authorization tests, and without a named owner to fix them when abuse begins.
Discovery must combine traffic and code
Traffic-based discovery finds what is actually served, including shadow and zombie endpoints, but it cannot see paths that receive no traffic during the observation window. Code and specification analysis finds declared routes, including those not yet deployed, but overstates coverage for anything behind feature flags.
Running both and reconciling the difference is what produces a defensible inventory. The reconciliation report is also the fastest way to identify ownership gaps: an endpoint that appears in traffic but in no repository is an accountability problem before it is a security problem.
- Passive traffic capture at gateway, mesh and load-balancer layers
- Specification ingestion from OpenAPI, GraphQL schemas and gRPC descriptors
- Reconciliation report listing served-but-undeclared and declared-but-unserved routes
- Ownership assignment as a blocking step, not a follow-up task
Authorization defects dominate real incidents
Broken object-level authorization and broken function-level authorization account for the majority of exploitable API findings we observe, well ahead of injection classes. They are also invisible to signature-based scanning: the request is syntactically valid, correctly authenticated, and returns data belonging to a different tenant.
Testing for them requires two authenticated identities and a differential expectation: identity A must not retrieve, modify or enumerate objects owned by identity B. This is cheap to automate in continuous integration and expensive to discover in production.
Business logic abuse is a detection problem
Credential stuffing, coupon enumeration, inventory hoarding and refund abuse use legitimate endpoints in legitimate ways at illegitimate rates or sequences. No schema violation occurs, so contract enforcement never triggers.
Detection therefore operates on behaviour per identity and per session: sequence deviation, ratio anomalies between related calls, and value distribution shifts. Because these detections govern revenue paths, they must be tuned against a labelled baseline before any blocking action is enabled.
Staged enforcement without breaking production
Enforcement is introduced in four stages, each with an exit criterion: observe, alert, enforce on non-production, enforce on production with a documented rollback. Skipping stages is the single most common cause of programs being suspended after the first incident caused by the control itself.
- Observe: 14 days of baseline per endpoint class, no policy action
- Alert: violations routed to the owning team with reproduction detail
- Constrained enforcement: rate and schema enforcement on non-production first
- Production enforcement: per-endpoint promotion with a one-command rollback path