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.
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
%00or 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.