Pentest API REST, GraphQL i OAuth — pełna checklista

Pentest API nie polega na wysłaniu skanera pod adres Swaggera. Najgroźniejsze błędy interfejsów REST i GraphQL wynikają z autoryzacji, logiki biznesowej, niepełnej inwentaryzacji oraz zaufania do danych zwracanych przez inne usługi. Żeby je znaleźć, tester potrzebuje co najmniej dwóch kont, kilku ról, dokumentacji i możliwości porównywania tego samego żądania w różnych kontekstach.

Ten przewodnik opisuje proces od rekonesansu do retestu. Nie powtarza tylko listy OWASP API Top 10 — pokazuje, jak zbudować macierz obiektów, funkcji, ról i tenantów, dzięki której wykrywa się BOLA, BFLA, mass assignment, nadużycia workflow i błędy OAuth.

Czym różni się pentest API od skanu

Skaner dobrze znajduje część błędów konfiguracji, niebezpieczne nagłówki, znane wersje, proste injection i brak limitów. Nie wie jednak, czy identyfikator invoice_id=7812 należy do zalogowanego użytkownika, czy rola konsultanta może zatwierdzić zwrot ani czy kupon wolno zastosować po opłaceniu zamówienia.

API jest warstwą logiki, nie tylko transportem HTTP. Ten sam endpoint może być bezpieczny dla jednego przepływu i podatny w innym. Ręczny pentest zmienia identyfikatory, role, kolejność, czas, typy danych oraz zależności między operacjami. Analizuje także efekty asynchroniczne: kolejki, webhooki, e-maile i statusy widoczne dopiero po czasie.

OWASP wskazuje, że autoryzacja pozostaje głównym problemem API — trzy z pierwszych pięciu kategorii OWASP API Security Top 10 2023 dotyczą kontroli dostępu. To obszar wymagający kontekstu użytkownika i biznesu.

Jak przygotować zakres pentestu API

Dobry scope powinien odpowiadać na pytania:

jakie hosty, wersje i środowiska obejmuje test;
czy API jest publiczne, partnerskie, mobilne czy wewnętrzne;
jakie protokoły występują: REST, GraphQL, SOAP, gRPC, WebSocket;
jak działa uwierzytelnianie: sesja, JWT, OAuth/OIDC, mTLS, API key;
jakie są role i granice tenantów;
które procesy są krytyczne: płatność, wypłata, zmiana właściciela, eksport, zaproszenie;
jakie integracje i webhooki przyjmują dane z zewnątrz;
jakie testy mogą zakłócić działanie i jakie limity są dozwolone;
czy tester ma OpenAPI/Swagger, kolekcję Postman, schemat GraphQL i kod źródłowy.

Minimalny zestaw kont to dwa konta zwykłe w oddzielnych tenantach oraz po jednym koncie dla każdej roli uprzywilejowanej. Jedno konto nie pozwala dobrze testować poziomego obejścia autoryzacji. Dane testowe powinny być rozpoznawalne, aby łatwo wykryć wyciek i usunąć artefakty.

Rekonesans i inwentaryzacja endpointów

OWASP WSTG API Reconnaissance zaleca rozpoczęcie od mapowania interfejsu. Tester zbiera dokumentację, pliki OpenAPI, schematy GraphQL, kod klienta, ruch aplikacji mobilnej i webowej, subdomeny oraz komunikaty błędów.

Nie wolno zakładać, że dokumentacja jest kompletna. Stare ścieżki /v1, eksperymentalne /beta, endpointy administracyjne, debug i hosty stagingowe często pozostają osiągalne. Warto porównać trasy widoczne w gatewayu, kodzie i specyfikacji.

Powstaje inwentarz zawierający metodę, ścieżkę, wymagane role, typ obiektu, parametry, spodziewany status i ograniczenia. Dla GraphQL potrzebna jest lista query, mutation, pól i dyrektyw. Dla OAuth — klienci, redirect URI, scope, granty oraz issuer.

Macierz autoryzacji: najważniejszy artefakt testu

Zamiast wykonywać losowe żądania, zbuduj macierz:

Operacja	Obiekt	Użytkownik A	Użytkownik B	Manager	Admin	Inny tenant
Odczyt faktury	invoice	własna	cudza	zespołu	wszystkie	zabronione
Aktualizacja profilu	user	własny	cudzy	ograniczona	pełna	zabronione
Eksport danych	tenant	brak	brak	dozwolony	dozwolony	zabronione
Zwrot płatności	transaction	brak	brak	limit	pełny	zabronione

Tester odtwarza poprawne żądanie i zmienia po jednym wymiarze: token, identyfikator obiektu, funkcję, tenant, pole lub kolejność. Tak wykrywa:

BOLA — dostęp do cudzego obiektu;
BFLA — wywołanie funkcji spoza roli;
BOPLA / mass assignment — odczyt lub zapis niedozwolonej właściwości;
brak separacji tenantów;
zaufanie do roli przekazanej przez klienta;
autoryzację sprawdzaną tylko w UI.

Najlepszym narzędziem jest różnicowe odtwarzanie żądań w dwóch sesjach. Odpowiedź 200 nie zawsze oznacza podatność, a 404 nie zawsze bezpieczeństwo. Trzeba potwierdzić zmianę danych i wpływ.

Checklista REST API

Uwierzytelnianie i sesja

Sprawdź rejestrację, reset hasła, MFA, odświeżanie tokenów, wylogowanie oraz unieważnienie po zmianie hasła. Token powinien mieć właściwego issuer, audience, czas życia i algorytm. Serwer nie może akceptować dowolnego alg, niepodpisanego JWT ani klucza wskazanego przez atakującego bez walidacji.

API keys muszą mieć zakres, rotację i możliwość unieważnienia. Klucz aplikacji mobilnej osadzony w APK nie jest sekretem użytkownika. Jeśli daje szerokie uprawnienia, napastnik może go wydobyć.

Walidacja obiektów i pól

Przetestuj dodatkowe pola JSON, wartości null, tablice zamiast skalarów, liczby ujemne, bardzo duże wartości, duplikaty kluczy i nieoczekiwane typy. Backend powinien używać allowlisty pól, szczególnie przy automatycznym mapowaniu requestu na model danych.

Sprawdź, czy odpowiedzi nie zawierają nadmiarowych danych: hashy, flag wewnętrznych, konfiguracji, tokenów lub pól innego użytkownika. Serializacja powinna być świadomie zaprojektowana.

Metody i formaty

Wypróbuj inne metody HTTP, Content-Type, alternatywne wersje i override headers. Czasem GET jest chroniony, a PUT lub PATCH korzysta z innej ścieżki autoryzacji. Parser JSON i gateway mogą też inaczej interpretować duplikaty lub zakodowane znaki.

Pliki, URL-e i webhooki

Upload wymaga kontroli typu, rozmiaru, nazwy, miejsca składowania i sposobu późniejszego serwowania. Funkcje pobierające URL lub wysyłające webhook są potencjalnym SSRF. Należy blokować sieci prywatne, metadata services, przekierowania i niebezpieczne schematy.

Checklista GraphQL

GraphQL zmniejsza liczbę endpointów, ale zwiększa elastyczność zapytania. Pentest powinien objąć:

introspekcję i ekspozycję schematu;
autoryzację na poziomie resolverów, obiektów i pól;
aliasy oraz batching obchodzące proste limity;
głębokość i koszt zapytań;
nested queries ujawniające cudze relacje;
mutation wykonywane poza rolą;
błędy zawierające stack trace lub dane wewnętrzne;
subskrypcje i WebSocket;
identyfikatory globalne, node lookup i caching.

Wyłączenie introspekcji w produkcji ogranicza wygodę rekonesansu, ale nie naprawia autoryzacji. Klient webowy często zawiera nazwy operacji, a błędy pomagają odtworzyć schemat. Każdy resolver powinien sprawdzać dostęp do konkretnego obiektu, nie polegać na wcześniejszym filtrze interfejsu.

Limity powinny uwzględniać koszt, nie tylko liczbę żądań. Jedno złożone query może obciążyć więcej niż sto prostych. Potrzebne są ograniczenia głębokości, złożoności, czasu i liczby wyników.

Checklista OAuth 2.0 i OpenID Connect

OAuth deleguje dostęp, a OIDC dodaje tożsamość. Tester analizuje pełny przepływ, nie tylko podpis tokenu:

dokładne dopasowanie redirect_uri;
użycie state przeciw CSRF;
PKCE dla klientów publicznych;
prawidłowe nonce w OIDC;
walidację issuer, audience i podpisu;
minimalne scope oraz zgodę użytkownika;
rotację refresh tokenów;
brak tokenów w URL, logach i referrerze;
account linking i zmianę adresu e-mail;
mieszanie tokenów między klientami i środowiskami;
bezpieczne wylogowanie oraz unieważnienie.

Szczególnie niebezpieczne są otwarte przekierowania połączone z niedokładną walidacją URI, przejęcie kodu bez PKCE i zaakceptowanie access tokenu jako ID tokenu. W integracjach wielu dostawców łatwo pomylić tożsamość z autoryzacją.

Logika biznesowa i wrażliwe przepływy

OWASP API6:2023 opisuje nieograniczony dostęp do wrażliwych procesów biznesowych. Przykłady to masowe zakładanie kont, wykupywanie limitowanego towaru, automatyczne rezerwacje, nadużycie kuponów i scraping.

Pentest sprawdza kolejność oraz powtórzenia:

czy płatność można zatwierdzić dwa razy;
czy refund przekracza wartość transakcji;
czy kupon da się użyć po zmianie koszyka;
czy zaproszenie działa po cofnięciu;
czy anulowane zlecenie można ponownie wykonać;
czy race condition omija limit;
czy krok można pominąć przez bezpośrednie wywołanie API;
czy operacja idempotentna rzeczywiście jest idempotentna.

Te testy wymagają rozmowy z właścicielem produktu. Tester bez wiedzy, co jest nadużyciem, może uznać niebezpieczne zachowanie za zgodne z projektem.

Unrestricted Resource Consumption

API4:2023 obejmuje nie tylko rate limiting. Należy sprawdzić koszt CPU, pamięci, bazy, zewnętrznych API, SMS-ów, e-maili i płatnych modeli AI. Tanie żądanie napastnika może generować drogie działanie po stronie firmy.

Testy destrukcyjne muszą mieć limity i zgodę. Zwykle wystarczy bezpieczny dowód: mała liczba równoległych żądań, analiza kodu albo test na stagingu. Celem nie jest wywołanie awarii produkcji.

Zabezpieczenia obejmują limity na użytkownika, tenant, IP i operację, kolejki, budżety, timeout, paginację, maksymalny rozmiar, circuit breaker oraz monitoring kosztu biznesowego.

Unsafe Consumption of APIs

Backend często ufa odpowiedzi innego API bardziej niż wejściu użytkownika. To błąd. Zewnętrzny dostawca może zostać przejęty, zwrócić nietypowe dane albo przekierować żądanie.

Tester sprawdza walidację odpowiedzi, podpis webhooka, replay protection, timeouty, przekierowania, TLS i ograniczenie danych. Sekret webhooka musi dać się rotować. Sam allowlist IP bywa niewystarczający, szczególnie w chmurze i usługach wielodzierżawnych.

Ten obszar łączy bezpieczeństwo API z ryzykiem dostawców i łańcuchem dostaw oprogramowania.

Raport, severity i retest

Raport powinien wskazać endpoint, rolę, obiekt, żądanie, odpowiedź, wymagane konta i rzeczywisty skutek. Przy BOLA potrzebny jest dowód dostępu do testowego obiektu innego użytkownika, nie tylko różnica statusu. Przy logice — opis sekwencji i stanu przed oraz po.

CVSS jest pomocny, ale wpływ biznesowy zależy od danych i procesu. Ten sam błąd autoryzacji może ujawnić publiczny profil albo dokumentację medyczną. OWASP zaznacza, że Top 10 nie wykonuje za organizację pełnej analizy ryzyka.

Retest powinien sprawdzić poprawkę w analogicznych endpointach. BOLA naprawiona w /invoices może nadal występować w /exports i wersji /v1. Warto dodać test regresyjny do CI i centralną funkcję autoryzacji.

Jak często testować API

Duży pentest warto wykonać przed uruchomieniem i po zmianie logowania, uprawnień, płatności, tenantów albo gatewaya. Szybko rozwijany system potrzebuje też testów zmian, automatycznego DAST/SAST/SCA i regularnego przeglądu inwentarza.

Nieudokumentowane API jest częstym problemem. Właściciel powinien znać wersję, konsumentów, dane, osobę odpowiedzialną i termin wyłączenia. API9:2023 podkreśla, że brak inwentaryzacji utrudnia aktualizacje i usuwanie starych interfejsów.

Najczęstsze pytania

Czy dokumentacja OpenAPI wystarczy do pentestu? Jest bardzo pomocna, ale może być niepełna. Tester porównuje ją z kodem klientów, gatewayem, ruchem i odkrytymi hostami.

Czy można testować produkcyjne API? Tak, jeśli istnieją zasady, bezpieczne dane i ograniczenia. Testy zasobów, wyścigów oraz masowych operacji lepiej wykonywać na wiernym stagingu.

Czy skaner wykryje BOLA? Czasem przy dobrze opisanych rolach i wielu sesjach, ale nie należy na tym polegać. Manualna macierz autoryzacji pozostaje kluczowa.

Czy pentest mobile obejmuje API? Nie automatycznie. Klient i backend powinny mieć jawne, skoordynowane zakresy. Więcej opisuje pentest aplikacji mobilnej.

Jak przygotować wycenę? Podaj hosty, protokoły, liczbę endpointów, role, tenanty, krytyczne procesy, dokumentację i ograniczenia. Czynniki kosztu opisaliśmy w artykule cena testu penetracyjnego.

Podsumowanie

Dobry pentest API łączy rekonesans, inwentaryzację, wielosesyjną macierz autoryzacji, testy REST/GraphQL/OAuth, logikę biznesową, zasoby i zaufanie do integracji. OWASP API Top 10 porządkuje ryzyka, ale nie jest checklistą do mechanicznego odhaczenia.

Największą wartość daje kontekst: jakie obiekty są poufne, kto może wykonać funkcję, gdzie przebiega granica tenantu i co oznacza nadużycie procesu. Jeśli planujesz test REST, GraphQL lub OAuth, prześlij dokumentację i role — na tej podstawie da się zbudować zakres, który mierzy realne ryzyko zamiast liczby endpointów.

Źródła i dalsza lektura: OWASP API Security Top 10 2023, OWASP API Reconnaissance, OWASP API Security Project, OWASP API risk methodology.