API endpoint discovery

Reference collection: the crawler already holds the HTML and the scripts of every page it fetched, and API calls leave their URLs in both. Those URLs are the first and most reliable source, because the site itself published them.

Conventional paths: a small set of paths an API is habitually served on is requested in addition — the kind any integrator would try first. This is a fixed list, not a generated one.

Anonymous request: each candidate is requested once, with no credentials and no crafted payload, and the status and content type are recorded.

Classification: endpoints that refused anonymous access are separated from endpoints that returned data. Both are reported, because the first group is evidence the access control works.

Every endpoint returning user-specific or internal data answers 401 or 403 without credentials.

The endpoints that do answer anonymously return data you would be comfortable publishing on a page — a catalogue, a public status, a set of reference values.

Every endpoint is served over HTTPS, so the tokens integrators send are never on the wire in clear.

And the inventory itself is short and recognisable: you can name the purpose of each entry in it.

An endpoint returning records with identifiers, email addresses or order details without any credential. This is the finding that matters most, and it is usually an endpoint someone built for an internal screen and never restricted.

An endpoint answering 200 with an empty list rather than 401. An empty list is not access control; it often becomes a full list the moment a query parameter is added.

An endpoint reachable over plain HTTP as well as HTTPS, which means any client that gets the scheme wrong sends its token in clear.

An inventory containing paths you did not know existed — typically an older version left running after a rewrite.

No path enumeration and no brute force. An endpoint that is not referenced anywhere in the site and is not on the conventional list will not be found, so an empty result is not proof that nothing else is exposed.

No credentials are ever supplied, so nothing behind authentication is examined at all.

No parameter is fuzzed and no payload is crafted. What is observed is what an ordinary client gets from an ordinary request.

A 403 is recorded as a refusal, and a refusal from a protection layer looks identical to a refusal from the application. The distinction needs a look at your own logs.

`api.surface.detected` builds the inventory from referenced and conventional paths. `api.endpoint.public_data` lists the endpoints that returned data anonymously, and `api.endpoint.protected` lists the ones that refused — reported as the expected behaviour rather than as a finding.

`api.transport.https` verifies each observed endpoint is served over HTTPS.

Endpoints that could not be reached are reported as not verifiable rather than as clean, which is the difference between a test that ran and a test that did not.

After a release that added or moved endpoints, since a route left behind by a refactor is the most common way an old surface stays reachable.

Before opening an API to integrators, as the inventory is the document the access-control review starts from.

After a framework or gateway upgrade, because default routes and debug endpoints are frequently re-enabled by a configuration reset.

On a schedule, for the same reason anyone keeps an asset inventory: the surface grows quietly and nobody notices which service added a route last month.