API Testing Checklist

Passive Reconnaissance

Active Reconnaissance

Endpoint Analysis

OR

API Documentation Conventions

ConventionExampleMeaning

: or {}

/user/:id

/user/{id}

/user/1337

/account/:username

/account/{username}

/account/mart1an

The colon or curly brackets are used by some APIs to indicate a path variable. In other words, “:id” represents the variable for an ID number and “{username}” represents the account username you are trying to access.

[]

/api/v1/user?find=[name]

Square brackets indicate that the input is optional.

||

“blue” || “green” || “red”

Double bars represent different possible values that can be used.

< >

<find-function>

Angle Brackets represent a DomString, which is a 16-bit string

Testing

Additional checks:

Mass Assignment Vulnerabilities

Mass Assignment with account registration for PrivEsc:

Admin Registration

POST /api/admin/create/user
Token: AdminAuthToken
-Redacted-
{
"username": "admin2",
"pass": "Iforgetit0ften",
"admin": true
}
POST /create/user
Token: StandardUserAuthToken
-Redacted-
{
"username": "tester",
"pass": "Test1234",
"admin": true
}

Blind Mass Assignment: If you suspect an API is vulnerable to Mass Assignment, there is a chance it may ignore the irrelevant variables and accept the variable that matches the expected name and format.

{
"username":"testern",
"email":"tester@site.com",
"admin": true,
"admin":1,
"isadmin": true,
"role":"admin",
"role":"administrator",
"user_priv": "admin",
"password":"Password1!"
}

Check different Content-Types

x-www-form-urlencoded --> user=test
application/json --> {"user": "test"}
application/xml --> <user>test</user>**

If it's regular POST data try sending arrays, dictionaries

username[]=John
username[$neq]=lalala**

If JSON is supported try to send unexpected data types

{"username": "John"}
{"username": true}
{"username": null}
{"username": 1}
{"username": [true]}
{"username": ["John", true]}
{"username": {"$neq": "lalala"}}**

If XML is supported, check for XXE

Last updated