Learning outcomes
- Inventory API hosts, versions, protocols, clients, objects, and administrative actions.
- Separate gateway route decisions from resource-server permission.
- Validate identity and credentials without losing actor or audience context.
- Test object, function, inventory, version, rate, and failure boundaries.
Protection need
An API exposes named operations over objects and system functions. Protect the complete inventory: public and private hosts, versions, methods, schemas, batch and export paths, administrative operations, callbacks, long-lived connections, and deprecated endpoints. Unknown or old APIs cannot receive complete policy.
Security objectives and requirements
Authenticate the client, workload, and human subject when each is relevant. Validate credential issuer, audience, status, and target. Select a canonical route. Enforce coarse exposure and route policy at the gateway. At the resource server, authorize the exact tenant, object, action, relationship, and current state. Validate input and output shape. Apply identity-aware abuse limits as a separate control.
Keep versions in policy and inventory until traffic and dependencies prove retirement.
Security invariants and evidence
- Every deployed API route and version has an owner and protection state.
- A gateway allow never replaces object and function authorization.
- Client, workload, and human actor remain distinct.
- Tokens are accepted only by their intended audience.
- Evidence correlates route, resource-server decision, object, action, result, and response.
Failure cases
- An attacker changes an object ID or calls a privileged function directly.
- A forgotten version lacks current policy.
- A batch or export path applies only one authorization check.
- A machine credential is treated as a human user.
- A broad scope replaces tenant and object permission.
- Schema or response data reveals fields the caller cannot access.
- Rate limits use only source IP and let one identity distribute abuse.
Design tradeoffs and residual risk
Central gateways improve inventory and common controls but can become a false authorization boundary. Fine resource policy improves precision but adds application work and data dependency. Short-lived tokens reduce replay but add issuer availability. Strict schemas reduce ambiguity but require disciplined versioning.
Use independent controls for exposure, credential validation, object permission, input safety, and abuse.
Pomerium boundary
Pomerium can protect API routes, authenticate human or service identities, and apply request policy before forwarding traffic. The API must validate any token it directly accepts, protect every deployed version, and authorize its own objects, functions, fields, and transactions.
Exercise
Inventory one API by host, version, route, method, object, action, client type, credential, and owner. Add tests for another tenant's object, administrative function, deprecated version, batch request, wrong audience, service credential with user-only action, and direct origin.
Connect gateway and API decision events with one correlation identifier.
Evaluation checklist
- Is every active and deprecated API version in inventory and policy?
- Are client, workload, and human identities represented separately?
- Does every object and function receive a local authorization check?
- Do wrong audience, old version, batch, export, and direct-origin tests deny safely?
- Can evidence trace the request from gateway route through final object action?
Next learning unit
Object and Action Authorization
Authorize every application action against the exact object instead of trusting route access, a role, or an object ID.
