API Testing in Depth: Auth, Negative Tests and Data Checks

Authentication in practice

AuthenticationAuthenticationChecking who a user is, usually with a password, a code or biometrics.Open in glossary → answers “who are you?”. APIs don’t have login screens, so every request has to carry proof. You’ll meet three kinds.

API keys

An API keyAPI keyA fixed secret string that identifies an app or partner calling an API, usually sent in a header.Open in glossary → is a long, fixed secret string issued to an application, a partner or a developer account, for example a restaurant’s point-of-sale system that pushes menu updates to FoodDash. It’s usually sent in a header:

GET /v1/partner/menus HTTP/1.1
Host: api.fooddash.test
x-api-key: test_pk_7Hq2...

What to test:

• No key, a wrong key, and a revoked key all return 401.
• A key for partner A can’t change partner B’s menu (403 or 404).
• Keys are not accepted in the URL (?api_key=...) if the docs say header only. URLs end up in logs and browser history.
• The key never appears in responses, error messages or the mobile app’s public code (ask developers how it’s protected).

Bearer tokens

After a user logs in (for example POST /auth/login with email and password), the server returns an access token, sent as a bearer tokenBearer tokenAn access token sent as Authorization: Bearer <token>; whoever holds it is treated as the user.Open in glossary →. The app sends it on every request:

GET /v1/users/me HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1XzEwMDEi...

“Bearer” means whoever holds this token is treated as the owner. Like a concert ticket, nobody checks your face, they check the ticket. That’s why tokens are treated like passwords: never in screenshots, public tickets or shared collections without masking. Tokens can be opaque (a random string the server looks up in a database, much like a session tokenSession tokenA string the server issues after login that proves who you are on later requests.Open in glossary →) or self-contained, which usually means a JWT.

JWT: what’s inside

A JWTJWTJSON Web Token: a signed token with three base64url parts (header, payload, signature) that APIs use to identify the caller.Open in glossary → (JSON Web Token, say “jot”) is three base64url-encoded parts joined by dots:

{ "alg": "HS256",
"typ": "JWT" }

{ "sub": "u_1001",
"role": "customer",
"exp": 1792230600 }

The payload holds claims. The standard ones you’ll see most:

Apps add their own claims too, like role, name or scope.

How to decode one. Copy the token from Postman or from DevTools › Network › a request › Headers › Authorization. Then paste it into a JWT decoder. The sandbox below has one built in. Online decoders such as jwt.io decode in your browser, but company policy may still forbid pasting tokens into external sites, so use test tokens only and ask first. Things to look at:

• Is exp there, and is the lifetime what the team agreed (15 minutes, not 15 years)?
• Is the role or scope right for this test user?
• Is there anything that shouldn’t be readable by the user, such as an email of another person, an internal flag or a password? A JWT is encoded, not encrypted. Anyone holding it can read it.

Token expiry and refresh

Access tokens are short-lived so a stolen token stops working soon. To avoid logging users out every 15 minutes, many apps also get a refresh tokenRefresh tokenA longer-lived token used only to get a new access token when the old one expires.Open in glossary →: a longer-lived token used only to ask the auth server for a new access token (POST /auth/refresh).

401 vs 403, tested properly

Repeating the request with the same credentials won’t fix a 403. A 401 means “authenticate (again)”, so apps usually react by refreshing the token or sending the user to the login screen. If the app logs users out on a 403, that’s a client bug worth reporting.

Authorization tests

AuthorizationAuthorizationChecking what a logged-in user is allowed to see or do.Open in glossary → answers “what may you do?” It must be checked by the server on every request, because anyone can send any request with their own valid token. Hiding a button in the app is not a security control.

You need at least two test accounts with the same role (Anna and Ben, both customers) and, ideally, one per role (customer, courier, restaurant owner, support agent, admin).

Horizontal access: same role, someone else’s data (IDOR)

This bug is called an IDORIDORInsecure Direct Object Reference: reaching another user's data by changing an ID in a URL or request.Open in glossary →, a form of broken access controlBroken access controlUsers can see or do things their role should not allow.Open in glossary →. Sequential IDs (1041, 1042, 1043) make it easier to exploit, but random IDs (UUIDs) don’t fix it. The ownership check does.

Vertical access: a normal user calling admin endpoints

List the privileged endpoints (from the OpenAPIOpenAPIA standard file format that describes an API's endpoints, parameters and responses (formerly called Swagger).Open in glossary → docs or by watching an admin session in DevTools): GET /admin/users, POST /refunds, PATCH /restaurants/3/commission. Call each one with a customer token. Expected: 403, and no side effect. Check afterwards that the refund wasn’t created anyway.

Sneaky fields (mass assignment)

Some APIs copy every field from the request body straight into the database. That bug is called mass assignmentMass assignmentA bug where an API saves every field from the request body, including ones the user must not change.Open in glossary →. Then a customer can send:

{ "name": "Anna", "role": "admin", "balance": 9999, "emailVerified": true }

Expected: unknown or protected fields are ignored (or rejected with 400), and a follow-up GET shows they didn’t change. This is often called mass assignment.

A role × endpoint matrix

Write it once, then test each cell:

Negative and boundary testing of requests

The server is the last line of defense: front-end checks can be skipped by anyone with Postman. Apply equivalence partitioning and boundary value analysis to every field, and break one thing at a time so you know which change caused the result.

Start from a valid request:

{
  "restaurantId": 1,
  "items": [{ "menuItemId": 101, "quantity": 2 }],
  "paymentMethod": "card",
  "note": "Leave at the door"
}

Duplicate submissions and idempotency keys

On a train with bad reception, the app sends POST /orders, the response gets lost, and the app (or the impatient user) sends it again. Without protection, the customer gets two dinners and two charges. That’s the API side of a double submitDouble submitA bug where an action runs twice because the user tapped or clicked twice quickly.Open in glossary →.

POST isn’t idempotentIdempotencyAn action that gives the same result no matter how many times it is repeated.Open in glossary → by nature, so many APIs accept an Idempotency-Key header (an idempotency keyIdempotency keyA unique value the client sends with a request so the server can recognize a retry and not repeat the action.Open in glossary →): a unique value the client generates once per user action (often a UUID). If the server sees the same key again, it returns the first response instead of creating a second order. Stripe and many payment APIs work this way, and there’s an IETF draft standard for the header.

Tests:

• Same key, same body, sent twice → the same order id both times, only one order in GET /orders.
• Same key, different body → an error (often 422 or 409), not a silent second order.
• Different keys → two orders (that’s correct: two real actions).
• No key, if the API requires one for payments → 400.

Validating responses beyond the status code

A 200 only says “the server didn’t complain”. Check the response in layers:

{
  "error": "validation_error",
  "message": "Some fields are invalid.",
  "details": [
    { "field": "items[0].quantity", "message": "must be from 1 to 20" }
  ],
  "requestId": "req_8f2k1"
}

{
  "error": "TypeError: Cannot read properties of undefined (reading 'map')",
  "stack": "at OrdersController.create (/srv/api/src/orders.js:42:9)"
}

Schema checks in Postman

A JSON SchemaJSON SchemaA JSON document that describes what valid JSON looks like: fields, types, required properties and allowed values.Open in glossary → is a JSON document that describes what valid JSON looks like: which fields, which types, which are required. Many teams generate it from their OpenAPI file. Postman can check a response against one:

const orderSchema = {
  type: "object",
  required: ["id", "status", "items", "total", "currency"],
  properties: {
    id: { type: "integer" },
    status: { enum: ["placed", "preparing", "on_the_way", "delivered", "canceled"] },
    total: { type: "number", minimum: 0 },
    currency: { type: "string", pattern: "^[A-Z]{3}$" },
    items: { type: "array", minItems: 1 }
  },
  not: { anyOf: [{ required: ["passwordHash"] }, { required: ["stack"] }] }
};

pm.test("Order matches the schema", () => {
  pm.response.to.have.jsonSchema(orderSchema);
});

The last rule (not … required) fails the test if a passwordHash or stack field ever appears. A one-line guard like that would have caught the FoodDash leak from the intro on day one.

Chaining requests: a CRUD flow with variables

Real tests are sequences: you create something, then use its id in the next request. That’s CRUDCRUDCreate, Read, Update, Delete: the four basic operations on stored data.Open in glossary →: Create, Read, Update, Delete.

Save the steps in one Postman collection folder and run it with the Collection Runner (or Newman, Postman’s command-line runner, in CI). Each run creates its own data and cleans up after itself, so it can run again and again.

Environments. A Postman environment is a named set of variables. You keep one for Dev and one for stagingStagingA pre-release environment that mirrors production as closely as possible.Open in glossary →, each with its own baseUrl and test-account tokens, and switch between them in the top-right dropdown. The requests themselves never change. Two habits:

• Keep tokens and keys in variables marked as secret and don’t share real secrets in team workspaces. Use test accounts only.
• Never point a destructive collection (one that deletes things) at production by accident. Some teams add a pre-request check that stops if baseUrl contains prod.

Lists: pagination, filtering and sorting

List endpoints break in quiet ways. A user never notices that restaurant #7 is missing, they just never order from it. (For the UI side, see the Pagination component.)

Page or offset paginationPaginationSplitting a long list into pages that load one at a time.Open in glossary → (?page=2&limit=20, or ?offset=20&limit=20):

• Walk every page with a small limit and collect the ids. No duplicates, nothing missing, and the count equals total.
• First page, last page, one past the last page (expect an empty list, not 500), page=0, page=-1, limit=0, limit=1, the maximum limit and maximum + 1, limit=abc.
• Add or delete an item between two page requests: with offset paging, items can shift and appear twice or not at all. That’s why many APIs use cursor paginationCursor paginationFetching the next items after a given item instead of skipping a count of items.Open in glossary → for feeds.

Filtering and sorting (?cuisine=italian&sort=-rating):

• Every returned item matches the filter. Combine two filters. Try a filter value that matches nothing (expect 200 with an empty list).
• The sort order is right, including ties (two restaurants with rating 4.5 must keep a stable order across pages) and descending (-rating).
• Unknown sort fields or invalid values give 400, not a silently ignored parameter.

Rate limiting: 429 and Retry-After

rate limitingRate limitingCapping how many requests a user or device can make in a period of time.Open in glossary → caps how many requests a client may send in a time window. When you go over, the API should answer 429 Too Many Requests, ideally with a Retry-After header that says how long to wait, in seconds (Retry-After: 30) or as a date. Many APIs also send headers like X-RateLimit-Limit and X-RateLimit-Remaining (common, but not a formal standard).

What to test, after agreeing on it with the team:

• The limit kicks in at the documented number, per user or per IP as documented, and resets after the window.
• The 429 response has a clear message and Retry-After. The blocked request has no side effect.
• The app handles 429 gracefully: it waits and retries with back-off (see retry with backoffRetry with backoffAutomatically trying a failed request again, waiting longer between each attempt.Open in glossary →) instead of showing a crash or hammering the server.

The Security Basics lesson covers which features need rate limits (login, codes, coupons).

Caching and ETags

Responses can be cached so the app doesn’t download the same restaurant menu 50 times. An ETagETagA version label the server sends with a response so clients can ask 'has this changed?' and get 304 if not.Open in glossary → is a version label the server puts on a response, like ETag: "r3-v3". Next time, the client sends it back in If-None-Match. If nothing changed, the server answers 304 Not Modified with an empty body and the client uses its cachedCacheStored copies of data or files that make apps and websites load faster.Open in glossary → copy.

Testers check:

• The ETag changes when the data changes. If a restaurant updates its menu and you still get 304 with the old ETag, users see stale prices.
• Personal data (profiles, orders) is not cached by shared caches: look for Cache-Control: no-store or private.
• For updates, some APIs use If-Match: “only save if the version is still X”. A stale ETag must get 412 Precondition Failed, which prevents two support agents from overwriting each other’s changes.

Versioning and backward compatibility

APIs change, but old clients don’t disappear. A mobile app from last year is still installed on thousands of phones and keeps calling the old API. That’s why APIs are versioned (API versioningAPI versioningKeeping several versions of an API (such as /v1 and /v2) so old apps keep working after breaking changes.Open in glossary →), usually in the path (/v1/orders, /v2/orders) or in a header.

Test ideas: run your v1 collection against every new release (it’s your regression suite for old apps), check that an unknown version like /v3 returns a clear 404, and install the oldest supported app version against the new back end before a release.

Contract testing automates part of this. The client team writes down exactly which requests it sends and which response fields it relies on (the contract), and the API’s build checks every change against those contracts, so a renamed field fails the build before it reaches users. Tools such as Pact do this; it’s mostly set up by developers, but knowing it exists helps you ask “is this endpoint covered by a contract testContract testingChecking that two services keep to their agreed API contract: fields, types and status codes.Open in glossary →?”

Example test cases