Pulseguard
Under Attack?API Discovery
Find the endpoints nobody documented.
Your API documentation describes the endpoints someone remembered to write down. Discovery finds the rest: the internal route left exposed, the v1 endpoint nothing was supposed to call any more, the admin action referenced from a shipped JavaScript bundle.
- Discovery sources
- 4
- Parameters inferred
- Per endpoint
- Undocumented routes
- Flagged
- Never called with a body
- Read-only
The endpoints nobody put in the docs.
Every row carries where it was found, how many parameters it takes, and whether it needs authentication. The ones marked undocumented are the reason this exists.
A tenant identifier accepted from the request body is exactly the shape of parameter worth testing by hand.
An undocumented endpoint is still an endpoint
Attack surface isn't what you designed. It's what responds.
Found from what actually runs
Endpoints are discovered from crawled pages, shipped JavaScript, and observed traffic, all sources that reflect the deployed system rather than a specification that may be months out of date.
Shadow APIs surface
Old versions, internal routes, and debugging endpoints that were never meant to be reachable are exactly what this finds, because it doesn't start from a list of what should exist.
Auth requirements recorded
Whether an endpoint requires authentication is captured per endpoint, which is what makes an unauthenticated internal route stand out immediately rather than blend into a list.
Parameters, not just paths
Each endpoint's parameters are recorded with their location (query, body, or header) and flagged when a name looks sensitive, like a tenant identifier accepted from a request body.
Feeds the rest of the platform
Discovered endpoints become part of your attack surface data, so they're available to prioritisation, to reports, and as a starting point in Security Lab.
Discovery, not exploitation
Finding an endpoint never means calling it with a payload. Discovery observes and records; anything beyond that is a decision you make deliberately in the workbench.
Four sources, one inventory
Each source finds a different class of endpoint, which is why none of them is sufficient on its own.
Crawled pages
Links, forms, and fetch targets found while crawling your site: the endpoints your own front end depends on.
Shipped JavaScript
Same-origin bundles are read for the routes they reference, which is where internal and admin endpoints most often leak.
Observed traffic
Requests seen through Security Lab sessions, recorded as endpoints rather than lost when the session closes.
Specification, for comparison
A supplied spec is used as the baseline of what should exist, so anything discovered outside it can be labelled undocumented.
How an endpoint gets recorded
Observe, attribute, infer, compare. No stage of this sends a request your application wasn't already going to receive.
- 1
Sources are gathered during a scan
The crawler's link graph, same-origin JavaScript assets, and any traffic captured in a workbench session are collected as part of the scan already running against your verified domain.
- 2
Each endpoint is attributed to its source
Endpoints record how they were discovered and with what confidence, so one referenced from a bundle reads differently from one observed serving a real response.
- 3
Parameters are inferred
Names and locations (query, body, or header) are recorded per endpoint, with a sensitivity guess on names that look like identifiers or secrets.
- 4
Everything is compared against the documented set
Discovered endpoints are diffed against the specification you supplied. Anything present in reality but absent from the docs is flagged, and anything documented but never seen is worth its own conversation.
- 5
The inventory stays in step with deploys
Because discovery re-runs with every scan, an endpoint added or removed in a release shows up as a change rather than needing anyone to remember to update a list.
API Discovery, answered.
No. Discovery records that an endpoint exists, where it was found, and what parameters it appears to take. No rule in PulseGuard sends a request with a state-changing body or attempts to bypass authentication. Testing an endpoint is something you choose to do in Security Lab, deliberately.
Find out what else is listening.
Run a scan and compare what responds against what anyone wrote down.