A request payload is the data sent to an API server in the body of a POST, PUT, or PATCH request. APIs use payloads to create or update resources, such as payments. Treat every payload as untrusted input: accepting fields beyond the intended schema can let an attacker alter server-side state or bypass business checks. section 1.4
Secure payload handling focuses on controlling both what clients may send and what the server does with it:
- Constrain the accepted fields and values to the resource’s intended user flow. section 1.8
- Reject unexpected properties rather than allowing clients to submit server-side fields or state-changing attributes. section 1.4 section 1.8
- Test payload validation continuously and automate vulnerability checks where possible. section 1.8
Payment update endpoint
Suppose an API accepts a payment payload containing the amount and destination account. The server checks whether the payer has sufficient funds. If the payload also accepts an unintended property that changes payment state, an attacker may submit that property and bypass the checks. Define an allowlist of permitted fields, reject extras, and verify the resulting state through automated tests. section 1.4 section 1.8
Figure 1.5 Every input parameter in an API represents an attack vector, including URLs, query and path parameters, request headers, and payloads. Unconstrained user input allows hackers to send malicious requests to our API to harm our system or cause unexpected behaviors.
Use the attack-surface figure to inspect payloads alongside URLs, query parameters, path parameters, and headers; unconstrained input in any of these locations can produce harmful or unexpected behavior. section 1.4
