Negative API Testing

Why it matters

Mobile apps, partner systems and scripts call an API without going through its user interface, so the API must enforce every rule itself. When it trusts its input, it stores corrupt data, crashes with a 500, leaks stack traces, or lets a client set properties it should never control, such as a price. The OWASP API Security Top 10 2023 lists that last case under API3, Broken Object Property Level Authorization.

Error responses are an interface too: clients read the status and the error body to decide what to show and whether to retry, so a changed error format breaks them like a changed success response. For a tester, the contract gives an exact expected result for every rejection, so negative API tests are precise and easy to automate.

Classes of invalid request and the status each one earns

Design negative API tests like the invalid partitions of equivalence partitioning: one class per test and every other part of the request valid, so that a failure points to one rule. The codes come from RFC 9110 and the lesson on REST APIs; where HTTP leaves a choice, such as 400 or 422 for invalid values, the contract decides.

• Malformed syntax: a truncated body, a trailing comma, an empty body declared as JSON → 400 Bad Request.
• Missing fields: each required field left out in turn, then sent as null and as "", which an API may treat differently → 400 or 422 naming the field.
• Wrong types: "2" instead of 2, 2.5 for an integer, an array instead of an object → 400 or 422, not a silent conversion.
• Invalid values: an unknown enum value, the date 2026-02-30, a property the client must not set such as "price": 0.01 → 422 or 400, or ignored if the contract says so, but never applied.
• Wrong media type: Content-Type: text/plain on a JSON body → 415 Unsupported Media Type.
• Wrong method: PUT on a path that supports only GET and POST → 405 Method Not Allowed with an Allow header. A supported method that this caller may not use gets 403, as in the lesson on authorization testing.
• Bad authentication: a missing, malformed or expired credential → 401 with WWW-Authenticate, as in the lesson on API authentication.
• Unknown resource: GET /api/v1/cart/items/99999 → 404 Not Found.

Try it: Negative Test Generator Try it: API Test Data Generator

Boundary testing for APIs

Boundary value analysis works on an API as on a form, but the boundaries are written in the OpenAPI schema. The JSON Schema keywords minimum, maximum, minLength, maxLength, minItems and maxItems (and the exclusive variants) each give a boundary and its neighbours. Query parameters have them too: a page size limit from 1 to 100 gives 0, 1, 100 and 101. RFC 9110 defines 422 for request content, so many APIs answer an invalid query parameter with 400 even when they use 422 for body values, as in the example below; the contract decides.

The contract must also say what happens beyond a limit: reject the request, or clamp the value, for example treat limit=500 as 100. Both are testable; unspecified behaviour is a question for the team. Some limits are never written in the schema at all: OWASP API4:2023, Unrestricted Resource Consumption, names missing limits such as records per page and maximum upload size.

• Large integers: RFC 8259 notes that implementations agree exactly on JSON integers only between -9007199254740991 and 9007199254740991 (2^53 - 1), so a JavaScript client can silently round a larger ID.
• Body size: just under and just over the documented limit, expecting 413 Content Too Large (RFC 9110) above it, on an environment you are allowed to load.

quantity (body):  { "type": "integer", "minimum": 1, "maximum": 10 }
  0 -> 422      1 -> 201      10 -> 201      11 -> 422

limit (query):    integer, 1..100, default 20
  0 -> 400      1 -> 200      100 -> 200     101 -> 400 (reject)
                                             101 -> 200, at most 100 items (clamp)

Try it: Boundary Value Generator Try it: OpenAPI → Test Cases

The error response contract: RFC 9457 problem details

A negative test needs an expected error body, not only a status. RFC 9457, Problem Details for HTTP APIs, which replaced RFC 7807, defines one: the media type application/problem+json and a JSON object with five standard members. An API may add extension members, such as a list of field errors, and clients must ignore extensions they do not recognise. In the example below, as in the RFC, each field error has a pointer: a JSON Pointer (RFC 6901) to the field in the request body, written in its URI fragment form #/quantity.

Your team does not have to use RFC 9457, but every endpoint should follow one documented format. Include the errors that the application code does not produce itself, such as a 404 from the router or a 413 from a proxy: they are the most likely to arrive in another format, sometimes as an HTML page.

• type: a URI for the kind of problem. Clients and tests branch on it, not on the wording of title. When it is absent, its value is about:blank.
• title: a short summary of the type, the same for every occurrence except for translation.
• status: if present, identical to the code in the status line, as RFC 9457 requires.
• detail: this occurrence, written to help the client correct the request, not to debug the server.
• instance: optional, a URI reference to this occurrence, useful for finding it in the logs.
• No internals: no stack trace, SQL, file path or version number, and no password or token echoed back. RFC 9457 warns against such leaks, and OWASP API8:2023 counts them as security misconfiguration.

HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json

{
  "type": "https://api.example.com/problems/validation-error",
  "title": "The request contains invalid fields.",
  "status": 422,
  "detail": "quantity must be between 1 and 10.",
  "errors": [
    { "pointer": "#/quantity", "detail": "must be between 1 and 10" }
  ]
}

Try it: Mock Error Response Generator Try it: API Response Validator

Worked example: negative tests for adding a cart item

Contract: POST /api/v1/cart/items needs a Bearer token and a JSON body with productId (integer, at least 1) and quantity (integer, 1 to 10). The path supports GET and POST; unknown properties are rejected. Errors use application/problem+json: 400 for a malformed body, 422 for invalid values. Each test starts with an empty cart, and product 42 exists.

Each test breaks one rule, and afterwards GET /api/v1/cart must still return an empty cart: a correct status with a stored item is still a failed test.

• NA-04 is one of four boundary tests for quantity: "quantity": 0 must also return 422, and its positive partners "quantity": 1 and "quantity": 10 must return 201.
• NA-09 breaks two rules on purpose to test precedence: the team agreed that credentials are checked before the body, so anonymous callers never learn the validation rules.
• If NA-05 returned 201 with a line price of 1.00 SAR, that is a critical defect: the client set the price.

ID     Request (one rule broken)                      Expected
NA-01  {"productId": 42, "quantity": 2,               400, problem+json
NA-02  {"quantity": 2}                                422, pointer #/productId
NA-03  {"productId": 42, "quantity": "2"}             422, pointer #/quantity
NA-04  {"productId": 42, "quantity": 11}              422, pointer #/quantity
NA-05  {"productId": 42, "quantity": 2, "price": 1}   422, pointer #/price
NA-06  valid body, Content-Type: text/plain           415
NA-07  PUT /api/v1/cart/items                         405, Allow: GET, POST
NA-08  valid body, no Authorization header            401, WWW-Authenticate: Bearer
NA-09  no Authorization header, {"quantity": 0}       401, not 422

Try it: REST API Tester Try it: API Request Builder

Frequently asked questions

References

• RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.
• RFC 9457: Problem Details for HTTP APIsIETF · 2023The application/problem+json error format (type, title, status, detail, instance) for machine-readable API errors.
• OWASP API Security Top 10 (2023)OWASP Foundation · 2023The ten most common API weaknesses: broken object-level authorization, broken authentication, unrestricted resource consumption and more.
• JSON Schema SpecificationJSON SchemaThe vocabulary for describing and validating the shape of JSON documents (types, required properties, formats).