External API attack surface testing with an autonomous agent
Most API breaches start on an endpoint nobody remembered was exposed. External API attack surface testing continuously discovers every API you have facing the internet, including shadow, undocumented, and zombie endpoints, then proves which of them an attacker could actually abuse. It is the first thing Operator does, from a single seed.
What the agent maps and tests
Every API you expose
Documented APIs plus the shadow, undocumented, and zombie endpoints missing from your register: old API versions, staging APIs left public, and hosts serving APIs you forgot about, rebuilt on every run.
Reachable and real
For each API, the reachable surface: operations, parameters, authentication flows, and the object identifiers an attacker could tamper with.
Exploited, not listed
The exposed APIs that actually matter, tested for BOLA, BFLA, and broken auth, then chained and reproduced, so you fix the path an intruder would walk, not a queue of maybes.
Drift is where the breach starts
The external API surface is the part of your estate you control least and change most. A deploy ships a new endpoint, an old API version keeps serving traffic after the client moved on, a staging API is made public for a demo and never locked down. These appear between engagements, which is exactly when a yearly test cannot see them.
Operator re maps and re tests the external API surface continuously, so exposure from drift becomes a proven finding the week it appears.
- Full API re discovery each run, including shadow and zombie endpoints.
- Fingerprinted down to frameworks and versions before testing.
- Proven exposure, not an inventory you still have to triage.
- Continuous, so drift never becomes a silent gap.
A shadow endpoint the spec never declared
This is the class of gap continuous external mapping is built to catch: an API path that works, serves data, and appears nowhere in what the organization believes it exposes.
- Crawled every host in the external inventory and pulled the JavaScript bundles they served, including an older bundle still live behind a CDN cache; it referenced
/api/v2/export, a path absent from the organization's published OpenAPI spec. - Called
GET /api/v2/export?format=csvdirectly against the production API host, sending no Authorization header at all. - The host returned
200 OKwith a CSV body of live records, instead of the401 Unauthorizedevery documented operation on the same host returns without a token. - Repeated the request from a separate network with no prior session or cookie state, confirming the endpoint was reachable to any anonymous client, not just the tester's authenticated session.
GET /api/v2/export?format=csv HTTP/1.1 Host: api.example.com HTTP/1.1 200 OK Content-Type: text/csv order_id,customer_email,total ord_50713,c****@example.com,482.00 ord_50714,c****@example.com,129.50
curl -s "https://api.example.com/api/v2/export?format=csv"
The endpoint was never missing an authorization rule for a specific role, it was missing from the inventory that authorization rules get applied to in the first place, the same gap behind most function-level authorization failures on paths nobody remembered to protect.
Shadow endpoints like this rarely surface in a spec review, because the spec is what they are missing from. The path shipped in an old JavaScript bundle that outlived its release, stayed reachable on the production API host, and was never wired into the middleware protecting the documented surface. Nobody flagged it in a threat model, because nobody knew it existed to model.
This is what continuous external discovery is for. On every deploy, Operator rebuilds the API inventory from the live surface rather than trusting the last spec it was handed, then treats every path it finds, documented or not, as something to authenticate against and test like a real function, the same way it tests a documented endpoint for missing function-level authorization. A path outside the spec earns no exemption. See how a finding like this is reproduced and verified before it reaches a report.
Illustrative example, not a specific customer result.
Common questions
What is external API attack surface testing?
It is the continuous discovery and testing of every API your organization exposes to the internet: documented endpoints, plus the shadow, undocumented, and zombie APIs missing from your inventory. It answers the question an attacker asks first, which is which of your APIs can I reach and abuse.
How is it different from attack surface management?
Attack surface management discovers and monitors the external footprint. External API attack surface testing goes a step further and proves which of those exposed APIs are actually exploitable, testing each operation for BOLA, BFLA, and broken auth with evidence, rather than just listing them.
Can it find APIs we forgot about?
That is the point. The agent rebuilds your external API inventory from a seed on every run, so a staging API left public, an old versioned endpoint still serving traffic, or a subdomain hosting an undocumented API is discovered and tested, not missed.
Looking for a specific sector instead of your external surface? See API penetration testing by industry.
See which APIs you actually expose
Give us a seed domain and the agent will map your external API surface and prove what an attacker could reach and abuse.