Testy bezpieczeństwa API dla REST i GraphQL
Dla zespołów wdrażających API REST i GraphQL to manualny test penetracyjny skupiony na podatnościach, których nie wykryją automaty: autoryzacja na poziomie obiektu i funkcji, nadużycia logiki biznesowej oraz obsługa tokenów. Testujemy tak, jak realny atakujący z ważnym tokenem o niskich uprawnieniach — enumerujemy obiekty, podszywamy się pod tożsamości i łączymy przepływy — a następnie przekazujemy powtarzalne dowody i poprawki zmapowane do OWASP API Security Top 10 (2023).
Co testujemy
Błędna autoryzacja na poziomie obiektu (BOLA/IDOR — API1:2023)
Podmieniamy identyfikatory obiektów, UUID-y i zagnieżdżone referencje między dwoma kontami, aby udowodnić, że jeden najemca odczyta lub zmodyfikuje dane innego.
Błędne uwierzytelnianie (API2:2023)
Atakujemy logowanie oraz wydawanie i odświeżanie tokenów: odporność na credential stuffing, słabe JWT (alg:none, pomieszanie HS256/RS256, brak weryfikacji podpisu), brak wygasania/unieważniania tokenów i obejście OTP/resetu hasła.
Błędna autoryzacja na poziomie właściwości / Mass Assignment (API3:2023)
Wstrzykujemy nieoczekiwane pola (role, isAdmin, balance, tenant_id) do żądań zapisu i sprawdzamy nadmierne ujawnianie właściwości, których klient nie powinien otrzymać.
Nieograniczone zużycie zasobów (API4:2023)
Badamy brak lub obejście limitów żądań, nieograniczoną paginację/rozmiar strony oraz kosztowne zapytania umożliwiające DoS warstwy aplikacji i amplifikację kosztów.
Błędna autoryzacja na poziomie funkcji (API5:2023)
Wywołujemy endpointy administracyjne i uprzywilejowane, zabronione metody HTTP i ukryte funkcje tokenem zwykłego użytkownika, aby ujawnić eskalację pionową uprawnień.
Nieograniczony dostęp do wrażliwych przepływów biznesowych (API6:2023)
Nadużywamy przepływów — zakupu, poleceń, kuponów, rejestracji, rezerwacji — pod kątem automatyzacji i logiki biznesowej, np. race conditions i manipulacji ujemną ilością.
Server-Side Request Forgery (API7:2023)
Testujemy parametry URL/webhook/import pod kątem SSRF do metadanych chmury (169.254.169.254), usług wewnętrznych i DNS-rebinding, w tym warianty blind/out-of-band.
Nadużycia specyficzne dla GraphQL
Ujawnianie introspekcji, ataki głębokim zagnieżdżeniem zapytań, batching aliasów/pól omijający limity oraz wstrzyknięcia przez argumenty resolverów.
Metodologia
- 1
Ustalenie zakresu i autoryzacja
Ustalamy pisemnie cele, środowiska, konta testowe (co najmniej dwie role/najemcy) i zasady zaangażowania oraz potwierdzamy, że jesteś właścicielem lub masz uprawnienie do testów, zanim wyślemy ruch.
- 2
Inwentaryzacja i rozpoznanie API (API9)
Zgodnie z WSTG enumerujemy endpointy z OpenAPI/Swagger, introspekcji GraphQL, ruchu aplikacji mobilnej/SPA i przechwyconego ruchu, mapując wersje oraz endpointy shadow i wycofane.
- 3
Analiza uwierzytelniania i sesji
Badamy przepływy OAuth2/OIDC, strukturę i podpis JWT, czas życia tokenu, odświeżanie i wylogowanie zgodnie z kontrolami WSTG-ATHN/WSTG-SESS.
- 4
Testy autoryzacji i logiki biznesowej
Kluczowa faza manualna: macierze BOLA/BFLA między rolami i najemcami (WSTG-ATHZ), mass assignment i nadużycia wrażliwych przepływów na dwóch żywych kontach.
- 5
Injection, błędna konfiguracja i zużycie
Testujemy injection (SQL/NoSQL/command), błędy konfiguracji (CORS, gadatliwe błędy, nagłówki), limity żądań i niebezpieczną konsumpcję zewnętrznych API.
- 6
Raport, retest i omówienie
Każde znalezisko zawiera dowód w postaci żądania/odpowiedzi, ocenę CVSS i rekomendacje; bezpłatny retest weryfikuje poprawki, po czym następuje omówienie z inżynierem.
Standardy i odniesienia
Co otrzymujesz
- Raport techniczny — Opis każdego znaleziska z krokami reprodukcji, surowym żądaniem/odpowiedzią, oceną CVSS i mapowaniem do OWASP API/WSTG.
- Podsumowanie dla zarządu — Jednostronicowa narracja ryzyka dla kierownictwa i audytorów, z ogólną oceną postawy i priorytetyzowanym planem naprawczym.
- Wskazówki naprawcze — Konkretne poprawki uwzględniające framework dla każdego problemu — kontrole autoryzacji, ograniczenia schematu, utwardzenie tokenów — bez ogólników.
- Bezpłatny retest i atestacja — Ponownie weryfikujemy naprawione znaleziska i wydajemy list atestacyjny odpowiedni dla klientów, partnerów i dowodów zgodności.
FAQ
Co musimy dostarczyć przed rozpoczęciem testu?+
Środowisko staging lub zbliżone do produkcji, dokumentację API (OpenAPI/Swagger lub schemat GraphQL, jeśli jest) oraz co najmniej dwa konta testowe na rolę/najemcę, abyśmy mogli udowodnić błędy autoryzacji. Do testów uwierzytelnionych potrzebujemy działających poświadczeń lub tokenów, a ewentualne allowlisty IP należy przygotować wcześniej.
Ile trwa pentest API?+
Typowe API REST lub GraphQL z 30–80 endpointami zajmuje 5–10 dni roboczych wraz z raportem. Głównymi czynnikami są liczba endpointów, liczba ról/najemców i złożoność przepływów biznesowych. Stały harmonogram i cenę otrzymujesz po krótkiej rozmowie zakresowej.
Czy testy zepsują produkcję lub ujawnią dane?+
Domyślnie testujemy niedestrukcyjnie i uzgadniamy potencjalnie zakłócające kontrole (rate-limit, klasy DoS) w oknie serwisowym. Preferujemy środowisko staging; jeśli testujemy produkcję, używamy oznaczonych danych testowych i nie modyfikujemy rzeczywistych rekordów klientów.
Czy bezpłatny retest jest w cenie?+
Tak. Po naprawie znalezisk przez Twój zespół weryfikujemy je ponownie bez dodatkowych opłat w uzgodnionym oknie i aktualizujemy status w raporcie, dając dowód, że problemy zostały faktycznie zamknięte.
Czy to legalne i jak wygląda autoryzacja?+
Testy wykonujemy wyłącznie na podstawie podpisanej zgody i uzgodnienia zakresu potwierdzającego, że jesteś właścicielem lub kontrolujesz cel. To czyni zaangażowanie legalnym, precyzyjnie definiuje zasoby w zakresie i chroni obie strony. Przez cały czas stosujemy ścisły dokument zasad zaangażowania.