API Testing

Bron: PortSwigger Web Security Academy Auteur: Johan Beysen

1. Wat is een API?

API = Application Programming Interface — een interface waarmee applicaties met elkaar communiceren via gestructureerde HTTP-requests en responses.

2. Recon — API Endpoints Vinden

Via Burp Crawl

Browse of crawl door de website totdat je een API-request tegenkomt in Burp, bijv.:

PATCH /api/user/wiener HTTP/2

Stuur deze door naar Repeater en ga backwards tracken door argumenten weg te laten:

PATCH /api/user     → 400 Error (geen identifier)
PATCH /api          → 302 Found ← Bingo! API root gevonden

Rechterklik in de response → Open in browser → API documentatie zichtbaar.

Bekende Documentatie Endpoints

/api
/swagger/index.html
/openapi.json
/api-docs
/graphql
/.well-known/openapi.json

Base path verkennen

Als je /api/swagger/v1/users/123 vindt, probeer ook:

/api/swagger/v1
/api/swagger
/api

Gebruik Intruder met een wordlist van veelgebruikte API-paden.

3. Interageren met API Endpoints

Door API-requests in Repeater te sturen en te variëren, leer je hoe de API reageert.

OPTIONS Method

Stuur een OPTIONS request op elk endpoint om te zien welke methodes toegestaan zijn:

OPTIONS /api/products/1 HTTP/2

HTTP/2 200 OK
Allow: GET, POST, PUT, DELETE, PATCH

Wat je uit OPTIONS leert

1. Toegestane HTTP methoden

Allow: GET, POST, PUT, DELETE, PATCH
→ DELETE is mogelijk — probeer product verwijderen zonder auth!

2. CORS configuratie

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, DELETE
Access-Control-Allow-Credentials: true
→ Controleer op CORS misconfiguratie!

3. Verborgen methoden

Request: GET /api/admin  → 403 Forbidden
Request: OPTIONS /api/admin → Allow: GET, POST, DELETE, TRACE
Request: TRACE /api/admin   → 200 OK ✓
→ TRACE kan onbeschermd zijn!

4. Content-Type requirements

Accept: application/json, application/xml
→ Server accepteert XML → probeer XXE!

5. API versie-info

API-Version: 2.1.3
Supported-Versions: 1.0, 2.0, 2.1
→ Oudere versies kunnen kwetsbaarheden hebben!

HTTP Methoden Overzicht

Method	Wat test je?	Typisch risico
`OPTIONS`	Welke methods zijn allowed	Verborgen/onbeschermde methods
`HEAD`	Zoals GET maar zonder body	Soms andere AC dan GET
`TRACE`	Echo van request	Info disclosure, XST
`CONNECT`	Tunnel setup	SSRF mogelijk
`PATCH` vs `PUT`	Partial vs full update	Verschillende AC rules

Reconnaissance Flow

# 1. Probeer OPTIONS op elk endpoint
OPTIONS /api/users
OPTIONS /api/admin
OPTIONS /api/products/1

# 2. Vergelijk Allow headers
/api/users  → Allow: GET, POST
/api/admin  → Allow: GET, POST, DELETE, PATCH  ← Extra methods!

# 3. Test die extra methods
DELETE /api/admin/users/123  ← Misschien geen AC check?

Praktisch Voorbeeld

# Stap 1: Discovery
OPTIONS /api/products/1/price
→ Allow: GET, PATCH

# Stap 2: Test PATCH zonder auth
PATCH /api/products/1/price
Content-Type: application/json
{"price": 0}
→ 200 OK ← Vulnerability! Geen AC check op PATCH

4. Server Side Parameter Pollution

Soms heb je API's die niet direct zichtbaar zijn maar server-side werken. Om deze in kaart te brengen heb je parameters nodig — waarvan je vaak op voorhand niet weet welke het zijn.

De kunst bestaat erin te kijken welke parameters mogelijk zijn en op deze manier te gaan manipuleren.

Dit kunnen zijn:

Query parameters
Form fields
Headers
URL Path parameters

Gebruikte Karakters

#  → %23  (URL-encoded)
&  → %26  (URL-encoded)
=  → %3D  (URL-encoded)

Burp tip

Ctrl+U of Ctrl+Shift+U in Burp Repeater zet geselecteerde tekst om naar URL-encoding.

Voorbeeld — Parameter Inject

# Origineel request
GET /api/userinfo?user=wiener

# Inject extra parameter via #
GET /api/userinfo?user=wiener%23foo
→ Wat de server ziet: user=wiener#foo
→ Alles na # kan als commentaar of tweede query behandeld worden

# Inject via &
GET /api/userinfo?user=wiener%26admin=true
→ Wat de server ziet: user=wiener&admin=true

Doel

Door parameters te injecteren probeer je interne server-side parameters te manipuleren die normaal niet via de client bereikbaar zijn.