API Testing
Bron: PortSwigger Web Security Academy Auteur: Johan Beysen | Fox & Fish Cybersecurity
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.
Fox & Fish Cybersecurity | Intern gebruik