APIs and GraphQL

A web API gives software a way to request data or operations. Browsers, mobile apps, and services can all be clients. HTTP and JSON are common choices, but APIs are broader than either one. The security decision belongs to the service, regardless of which interface a client uses.

Three permission questions

Object-level authorization asks which record the caller may use. Function-level authorization asks which operation they may invoke. Property-level authorization asks which fields they may read or change. Mass assignment is one way property checks fail: automatic binding accepts client-controlled values for sensitive state.

An unexpected JSON field alone is not proof of a flaw. It matters whether the service accepts it, gives it sensitive meaning, and violates the intended policy. List, search, export, and batch operations must also preserve object and tenant boundaries.

Scenario: the booking service

A traveler may view their trip and change a contact address. A support agent may issue certain refunds under a separate policy. The server controls price and refund approval state; those values do not become writable just because the client sends them.

Retries complicate the refund operation. An idempotency key needs a defined scope, ownership, lifetime, and relationship to the request. It helps avoid duplicate processing, but does not replace authorization or make every distributed operation exactly once.

Schemas describe; they do not grant access

OpenAPI describes HTTP interfaces. GraphQL exposes a typed execution model with queries, mutations, and potentially subscriptions. Introspection is a schema feature, not a vulnerability by itself. Decide what documentation may be public, then enforce access regardless of its visibility.

GraphQL checks must cover all routes to sensitive data, including nested fields. Limits on depth help, but shallow queries can still be expensive. Consider operation cost, collection sizes, batch size, timeouts, and cancellation as well as request counts.

Different interfaces, shared principles

JSON-RPC describes named remote procedure calls; it is not simply REST with another spelling. SOAP and gRPC have their own message models and tooling. Their permission and data-boundary questions remain familiar.

Token validation should reflect issuer, audience, purpose, and trusted claim semantics. A schema, API gateway, or CORS policy cannot automatically supply every business-level permission check.

Review a contract, not just a URL

Document callers, permitted operations and fields, resource ownership, data sensitivity, cost budgets, and retry behavior. A large accepted page size is a reason to examine actual resource limits, not automatic proof of an outage. Explain the observed control gap and supported impact separately.

Turn an API description into enforceable rules

The fictional booking team gives you this contract. A traveler can read their own booking and change its contact address. A support agent assigned to that booking can request a refund. The server decides price and approval state. Refund requests use an idempotency key scoped to the caller and operation.

The contract separates a resource, an operation, and writable properties. A valid session, a well-formed JSON body, and a documented endpoint are useful facts but do not establish all three permissions.

PredictAn unchanged refund request is retried with the same key by the same caller. Should the server treat the key as permission to issue a new refund?

The key relates the retry to the prior operation under the service’s retry contract. Authorization still applies. The service should preserve the defined duplicate-handling behavior, and reject or otherwise handle a changed request under that key according to its documented rules.

Cost needs a contract too. Suppose a request may select at most twenty records and has a cost budget of fifty units. The supplied estimate is three units per selected record. A request for twenty records satisfies the count limit but costs sixty units, exceeding the cost budget. These are fictional units for this exercise; real estimates need calibration against the work actually performed.

A gateway request-count limit cannot express every nested field’s cost or each booking’s ownership. Enforce the relevant rules at the components that understand them, and record how retries, partial failures, and cancellation affect state and resource consumption.

Verification should compare permitted operations with refused alternatives using supplied test records. Include batch and export paths: one correct single-record response does not establish that every record in a collection receives the same protection.