When the Surface Is Not the Vulnerability

Claude-Red’s web and API skills ask a sharper question than “Which payload works?” They ask what an identity is allowed to do to an object, which function can be reached, what state a transaction occupies, and what side effects follow from a request. This chapter uses those skills to show how application security becomes context-sensitive: the same endpoint can be safe or dangerous depending on the user, tenant, protocol, timing, and state. Readers will gain a way to reason about authorization and business logic without reducing either to a flat checklist.

Authorization belongs to the request’s context

An API request carries more than a path. It carries an identity, an object identifier, a function or method, a representation of the data, and often a protocol-specific set of headers or metadata. The server’s security decision should account for all of those elements. Claude-Red’s API-security skill makes this visible by placing object-level authorization, function-level authorization, authentication lifecycle, content types, HTTP verbs, gRPC metadata, WebSocket origins, and API versioning in the same testing workflow.

Broken object-level authorization, often shortened to BOLA, occurs when an authenticated user can reach an object belonging to another user or tenant. The important relationship is between the caller and the object. A request may be perfectly valid in form: the token is accepted, the route exists, and the response is well-formed. The failure is that the server treats an identifier supplied by the caller as sufficient authority.

Broken function-level authorization, or BFLA, is different. Here the object may be the caller’s own account, but the caller can invoke a function reserved for a more privileged role. An ordinary account reaching an administrative operation is not the same failure as an ordinary account reading another customer’s record. The distinction affects root cause, evidence, remediation, and the defenders who need to monitor it.

Claude-Red’s value is in keeping these questions adjacent without merging them. Its workflow first maps the API and authentication model, then tests object and function boundaries across relevant identities. That ordering matters. A reader who starts with a collection of paths may discover that an endpoint exists, but not whether the server makes a decision about the caller, the object, and the requested capability independently.

The same principle applies to HTTP method and representation. A service may protect a resource when it is read through one method but apply a weaker check when it is updated or deleted. A parser may interpret duplicate parameters differently from a gateway in front of it. A JSON request and an XML or form-encoded request may reach different validation paths. These are not exotic details for their own sake. They are alternate routes through which state and authority are interpreted.

The API skill extends the problem beyond ordinary HTTP. gRPC exposes service and method boundaries through a different interface, and metadata can influence how a request is classified.