Lesson 2 · Free preview · 16 min

Testing methods, parameters, and content types

Swap the verb, change the type, add a parameter, and see what the server does.

On this page

Change the HTTP method

Take a working GET /api/orders/123 and try POST, PUT, PATCH, DELETE, HEAD, OPTIONS. A PATCH that the UI never issues may skip authorisation checks the GET enforces.

Change the content type

If the endpoint expects JSON, try:

  • application/x-www-form-urlencoded — sometimes parsed by a more permissive binder.
  • application/xml — may open XXE.
  • adding %00 or a charset trick.

Add parameters the UI omits

From your recon list, add fields to write requests:

PATCH /api/users/1543
{"name":"Alice","roleid":1,"emailVerified":true}

Watch for the field being reflected back changed, or an error that confirms it is recognised.

Test identifiers for BOLA / IDOR

Change 123 to 124, to a GUID you saw elsewhere, to a negative number. If you can read or modify another user's object, that is broken object-level authorisation — the most common serious API bug.

Tip

Keep two accounts. Do every action as account A, then replay the request with account B's session and A's IDs.