api

API Surface Detection

Overview

Every dynamic application is built on an API, and the API almost always accepts more than the front end sends: endpoints nobody links to, versions nobody retired, HTTP methods nobody intended, parameters nobody documented, and object properties the framework binds because it binds everything. Separately, when a public handler builds a request to an internal service by pasting user input into a URL, a path segment, or a JSON body, the caller can inject or override parameters in that internal request. Both sit in the same place in the lifecycle — after routing, at the point where the application decides which fields of the request it will honour and how it forwards them onward. The attacker is anyone who can reach the endpoint, usually an authenticated low-privilege user who interacts with the API directly rather than through the UI. What they gain is a property they should not be able to set, an operation the documented surface never offered, or control over a parameter in a request made on their behalf by a component they cannot reach. This skill finds such exposure by locating every binding site, unguarded surface, and internal-request assembly point, checking each one in parallel, and merging the results into <output_dir>/api-results.md.

What it is NOT

This skill's boundary with /websec:access-control is the one that matters most, so state it in every finding.

• Object-level and function-level authorization (/websec:access-control): "may this caller touch this object or invoke this function". Discriminating test — if the fix is an ownership or role check on a field and an operation that were both intended to exist, it belongs there. This skill owns property-level and surface-level exposure: "does this property bind, does this endpoint or version exist, does this parameter reach an internal request at all". If the fix is removing the field from the binding set, retiring or guarding a route or version, constraining the methods, or encoding input before it is embedded, it belongs here. A body that sets owner_id to another user's id is judged here as a binding failure and cross-referenced there for the authorization consequence.
• Server-side request forgery (/websec:ssrf): the attacker chooses the destination of the outbound request. In parameter pollution the destination is fixed and the attacker steers parameters within the request the application already makes. They chain; classify by which one the code actually permits.
• Prototype pollution (/websec:prototype-pollution): unrelated despite the similar name — that is object-prototype corruption in the runtime, not parameters in a request.
• Path traversal (/websec:path-traversal): traversal that resolves against the filesystem belongs there. Encoded traversal injected into an internal REST path, resolving to a different API resource, is judged here.
• GraphQL (/websec:graphql): a GraphQL endpoint's schema, resolvers, and operation limits belong there.
• Injection classes (/websec:sql-injection, /websec:nosql-injection, /websec:xxe): reached through an API but owned by their own skills. A content-type branch that routes a body into an XML parser is a candidate here; the parser's entity configuration is /websec:xxe.
• Model-driven endpoints (/websec:llm): an endpoint whose request or response passes through a language model, or that exposes a tool the model can call, is judged there — the binding set is decided by a tool definition rather than a serialiser. Test: does a model choose what this endpoint receives or does with the input?
• Domain rules on a bindable field (/websec:business-logic): this skill owns fields that should not be bindable at all — the binding set is too wide and the fix is to remove the property from it. A field the caller is legitimately allowed to send, carrying a value that violates a rule (a negative quantity, a discount past its cap, a backdated effective date), is theirs. Test: should this property bind at all, or does it bind correctly and simply go unvalidated?
• Information disclosure (/websec:information-disclosure): verbose errors that hand back the shape of a valid request are noted, not classified here.
• Surface decided outside this tree: which paths, versions, and methods are actually exposed can be a gateway's route table rather than this repository's router. Read the "Enforced where" column and the trust-boundary section of architecture.md before reporting a stale version or an internal handler as exposed surface — a version tree the edge does not publish is reachable only from inside. Judge that configuration where it is readable; where it is not, the label is NEEDS MANUAL REVIEW naming it. What is judged here: whether the handler is safe when reached directly, since a route unreachable only by convention is reachable to anything already inside the boundary. Binding is different — a body bound onto an entity is a sink in this code, and no external layer changes that.
• Not a finding: an extra field in a response that is not bindable on any write path; an endpoint that is merely unlinked but properly authorized; a deprecated version that is documented but not routed; a scanner-style "input was transformed" lead with no traced path.