YanoSec
Progress0 of 152 lessons complete

Course / 09 Web security / Lesson 14 of 28

API testing

Estimated time: 16 min reading · 12 min activity

An application programming interface, or API, defines requests that software can make. An endpoint combines a route with an operation. In this card, GET /notes/7 reads note 7 and PATCH /notes/7 changes its text. The path selects the resource; the method selects the action.

Authorization must cover the caller, action and object together. The member role may read its own note, while the editor role may read and change its own note. Documentation describing PATCH explains the interface, but does not grant that action to every caller.

Before you begin

Estimated time
16 min reading, 12 min activity. Setup and optional practice may take longer.
Where you work
Read the original fictional requests, source fragments and state tables in a current desktop or mobile browser. The required activity needs no server, database, account or installed security tool. Do not send the printed requests to any service.
Without a lab
Use the complete printed evidence to trace the data or state on paper. Write the decision, the fact supporting it and one limit of the model, then compare with the activity rubric. This does not establish live service behavior. Reading works without JavaScript. Checking requires JavaScript and a secure browser context; saving also requires usable browser storage.

After this lesson you can:

  • Name the action of GET /notes/7 and of PATCH /notes/7.
  • Decide the activity caller, an editor PATCHing their note.
  • Keep the member PATCH case for the question.

01Example

This fictional request demonstrates how role, method and object select a permission row. You will use a different role and method in the activity.

Caller role: member
Request: GET /notes/7
Ownership: caller owns note 7
Matrix decision: allowed
The request path alone did not decide access.

02Role, method, and object

Use the matrix in order: identify the caller's role, identify the requested method, then apply the ownership rule. The worked member GET is allowed. For the activity, change both the role and method to editor PATCH before choosing the matrix row. Do not transfer a permission from another role just because the path is identical.

Enforce the matrix at the server for each method and resource. A successful read cannot authorize a later change. Record the policy row and modeled response when making a finding; API documentation by itself does not establish which permissions a real request receives.

Read a method as the action and a path as the object, then apply the role matrix.Model. A teaching model drawn by hand. It shows the idea, not real tool output.

Read the full explanation below.

Match the explicit rowRead only the path
Caller role

Caller role: member

met · member
Method and object

Request: GET /notes/7

met · GET /notes/7
Ownership

Ownership: caller owns note 7

met · Caller owns note 7.
Apply the stated rule
Allowed

The explicit matrix row combines role, method, object and ownership.

Permission depends on role, method and object policy; a successful read does not authorize a change.

The explicit matrix row combines role, method, object and ownership.

Follow the explanation

  1. The explicit matrix row combines role, method, object and ownership.
  2. The provided allowed row depends on all three facts; the path is not a grant.
Read every state and value

1. The explicit matrix row combines role, method, object and ownership.

Case
matrix
Conditions inspected
Caller role · Method and object · Ownership
Decision shown
Yes

2. The provided allowed row depends on all three facts; the path is not a grant.

Case
path
Conditions inspected
Caller role · Method and object · Ownership
Decision shown
Yes
Permission depends on role, method and object policy; a successful read does not authorize a change.

03Decide the editor PATCH

Read the evidence before comparing your reasoning with the activity rubric. Do not call a live API.

Owned notes API. No server was started.

GET /notes/7
  action: read the note
  body: none

PATCH /notes/7
  action: replace the note text
  body: a JSON object with a text field

The path names the object. The method names the action.
A page that documents both methods is not a grant to call both.

Download the API card

{
  "activity": {"caller": "editor", "method": "PATCH", "path": "/notes/7"},
  "worked": {"caller": "member", "method": "GET", "path": "/notes/7"}
}

Download the two callers

role,method,object_rule,decision
member,GET,own note,allowed
member,PATCH,own note,denied
editor,GET,own note,allowed
editor,PATCH,own note,allowed
guest,GET,any note,denied

Download the permission matrix

  1. Read the activity object in the requests file. Write the caller and the method.
  2. Find that role and method on the matrix.
  3. Check: the editor may PATCH their own note. The worked caller is the member GET, which is also allowed and is a different row.
  4. Stop. Do not send the request to a real notes service.

04Optional challenge

Draft one evidence line for a refused request using only fake ids. The rubric is: caller, method, path, and the matrix row, with no real key. About ten minutes.

05Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

API case A: request meaningsOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

GET /notes/23 reads note 23.
PATCH /notes/23 replaces note 23 text using a JSON text field.
The path chooses the object; the method chooses the action. No API call is made.

API case B: fresh permission matrixOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

Member: may GET own notes; may not PATCH.
Editor: may GET or PATCH own notes only.
Guest: neither action.
P: member, GET, owns note 23.
Q: member, PATCH, owns note 24.
R: editor, PATCH, does not own note 25.

API case C: incomplete source ruleOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

Handler: if caller.role == editor and method == PATCH, replace requested note text.
Policy still requires the editor to own the requested note.
The handler does not compare caller identity with the stored owner.

06Explain your evidence

Optional written self-check: explain one decision using the supplied case. No tool run is required.

Check your explanation: identify method and object; evaluate role and ownership together; cite the exact policy row; locate the missing condition at the server operation rather than inferring permission from documentation or UI.

07Common mistakes

If you decide the editor from the member row, you switched roles. The activity caller is editor.

If you allow every method because the caller owns the note, you skipped the action column.

If you treat the spec page as permission, the matrix is the decision.

References

  • RFC 9110: HTTP semantics

    Section 9.2.1. Safe method semantics do not prove the absence of side effects. The card defines GET and PATCH for this lesson. No request was sent.

  • PortSwigger: API testing

    Explains the failure mechanism and prevention. Use it for further reading after reasoning from this page's original model; a topic page is not evidence that a lab was launched.