Każda nowoczesna aplikacja, którą dziś budujesz lub od której zależy Twój biznes, jest w gruncie rzeczy zbiorem API połączonych ze sobą cienką warstwą interfejsu użytkownika. Aplikacja mobilna rozmawia z backendem przez REST, frontend webowy ciągnie dane z GraphQL, integracje z dostawcami chodzą przez webhooki, a wewnętrzne mikroserwisy wymieniają informacje przez gRPC. Atakujący to widzą — i kierują tam większość wysiłku.
OWASP API Security Top 10 w edycji z 2023 roku jest dziś tym, czym OWASP Top 10 dla aplikacji webowych był dekadę temu — wspólnym językiem dla zespołów developerskich, pentesterów i działów compliance. Tyle że API to inny attack surface niż klasyczna aplikacja webowa. Nie ma przeglądarki, która egzekwowałaby Content Security Policy, nie ma renderowanego HTML, w którym mógłby zadziałać XSS w klasycznej formie. Za to jest mnóstwo endpointów, każdy z własnym kontraktem, własną logiką autoryzacji i własnym potencjałem do nadużycia.
Ten przewodnik prowadzi przez wszystkie dziesięć kategorii listy z 2023 roku, pokazuje typowy scenariusz nadużycia, sugeruje sposób testowania i kończy się praktyczną checklistą dwunastu kroków pentestu API oraz mapowaniem na obowiązujące w Polsce regulacje — w tym PCI DSS 4.0, NIS2 i DORA.
Dlaczego OWASP Web Top 10 nie wystarcza do API
Warto zacząć od tego, dlaczego w ogóle istnieje osobna lista. OWASP Top 10 dla aplikacji webowych (edycja 2021, nadal aktualny standard) opisuje świat, w którym między atakującym a serwerem aplikacji stoi przeglądarka — i większość klasycznych zabezpieczeń (CSP, SameSite cookies, escapowanie HTML, walidacja inputu po stronie klienta) opiera się na tym założeniu. API nie ma przeglądarki. Klient API to często skrypt, mobilka albo inny mikroserwis, który wykona każde żądanie, jakie mu się każe wykonać.
W praktyce oznacza to przesunięcie środka ciężkości problemów. W aplikacji webowej długo dominowały injection i XSS. W API dominują problemy autoryzacji — kto ma prawo zobaczyć ten obiekt, zmienić to pole, wywołać tę funkcję. OWASP API Security Top 10 (2023) wprost stawia na pierwszych pięciu miejscach trzy różne odmiany broken authorization (BOLA, BOPLA, BFLA) oraz broken authentication i nadużycia wrażliwych przepływów biznesowych. To nie przypadek — to konsekwencja tego, że API daje atakującemu bezpośredni dostęp do logiki domeny, bez warstwy UI, która tradycyjnie maskowała niedostatki autoryzacji w backendzie.
Główna różnica: W aplikacji webowej UI ukrywa istnienie pewnych endpointów i danych. W API wszystkie endpointy są wystawione wprost i opisane w specyfikacji OpenAPI lub Swagger. To, czego nie zabezpieczy backend, atakujący znajdzie w pięć minut.
API1:2023 Broken Object Level Authorization (BOLA)
BOLA — historycznie znany jako IDOR (Insecure Direct Object Reference) — pozostaje najczęstszym i najpoważniejszym problemem API. Występuje, gdy endpoint przyjmuje identyfikator obiektu w żądaniu i zwraca dane, nie weryfikując, czy zalogowany użytkownik ma prawo do tego konkretnego obiektu.
Klasyczny PoC: aplikacja e-commerce ma endpoint GET /api/v1/orders/12345. Zalogowany użytkownik widzi swoje zamówienie. Atakujący zmienia ID na 12346 i widzi cudze zamówienie razem z danymi osobowymi i adresem dostawy. Backend sprawdził, że użytkownik jest zalogowany (uwierzytelnienie), ale nie sprawdził, że obiekt 12346 należy do tego użytkownika (autoryzacja).
Test polega na inkrementacji i dekrementacji ID, podmianie UUID-a na cudzy (przechwyconego z innej sesji testowej) oraz na sprawdzeniu odpowiedzi przy ID, które nie istnieją w bazie kontrolnej. Burp Suite z rozszerzeniem Autorize automatyzuje porównanie odpowiedzi dla dwóch użytkowników o różnych rolach. Obrona wymaga centralnej warstwy autoryzacji, która przy każdym dostępie do obiektu sprawdza relację właściciel/uprawnienie — nie polegania na tym, że frontend nie pokazuje guzika.
API2:2023 Broken Authentication
Druga kategoria obejmuje wszystko, co psuje proces uwierzytelnienia: słabe mechanizmy logowania, brak rate limitingu na endpoincie loginu, możliwość brute-force, błędy w obsłudze tokenów JWT, słabe procesy odzyskiwania hasła oraz tokeny sesji niewygasające w sensowny sposób.
Typowy PoC dotyczy JWT. Atakujący przechwytuje token, zmienia algorytm w nagłówku z RS256 na none (jeśli biblioteka serwerowa pochopnie akceptuje algorytm wskazany przez klienta) lub podmienia algorytm na HS256 i podpisuje token kluczem publicznym RSA traktowanym jak sekret HMAC. W obu wariantach efekt to forgery dowolnego tokena, w tym tokena administratora.
Test obejmuje sprawdzenie, czy serwer akceptuje algorytm none, czy weryfikuje sygnaturę, czy stosuje rotację kluczy, czy endpoint loginu ma rate limiting, czy obsługa „zapomniałem hasła” nie ujawnia, które adresy email istnieją w bazie, oraz czy proces resetu nie pozwala na przejęcie konta przez przewidywalny token. JWT.io i Burp Suite z rozszerzeniem JWT Editor to standardowe narzędzia.
API3:2023 Broken Object Property Level Authorization (BOPLA)
BOPLA to kategoria, która łączy dwa historyczne problemy: mass assignment (zalewanie obiektu polami, których atakujący nie powinien móc ustawić) oraz excessive data exposure (zwracanie w odpowiedzi pól, których atakujący nie powinien widzieć).
PoC mass assignment: endpoint PATCH /api/v1/users/me przyjmuje JSON {"email": "..."}. Atakujący dorzuca do JSON-a pole {"role": "admin"} i backend, używając słabej deserializacji do encji bazodanowej, podnosi go do administratora.
PoC excessive data exposure: endpoint GET /api/v1/users/me zwraca pełny obiekt użytkownika, w tym hash hasła, klucz API, pola wewnętrzne typu is_internal_employee. Frontend wybiera z odpowiedzi tylko nazwę i avatar, ale wszystko jest dostępne dla każdego, kto otworzy DevTools.
Test polega na fuzzingu pól w żądaniu (które pola backend „połknie” i zapisze) oraz na inspekcji odpowiedzi i porównaniu jej z tym, co rzeczywiście jest pokazywane w UI. Obrona to explicit whitelist pól dozwolonych do zapisu i osobny DTO dla każdej odpowiedzi, zamiast serializacji surowych encji.
API4:2023 Unrestricted Resource Consumption
Czwarta kategoria dotyczy braku ograniczeń na zużycie zasobów — CPU, pamięci, ruchu sieciowego, połączeń do bazy, kosztów zewnętrznych API (SMS, email, OCR, modele LLM). Bez rate limitingu i quoty atakujący może wywołać atak typu denial of wallet — koszt nie jest dla serwisu w postaci downtime, lecz w postaci faktury od dostawcy SMS lub OpenAI.
PoC: aplikacja udostępnia endpoint generujący raport PDF na żądanie. Wywołanie kosztuje 200 ms CPU. Atakujący wywołuje endpoint w pętli z dziesięciu wątków przez godzinę. Inny scenariusz: endpoint logowania wysyła kod SMS przy każdym żądaniu, bez limitu prób per numer.
Test obejmuje sprawdzenie limitów per IP, per użytkownik, per klucz API, limitów na rozmiar żądania (Content-Length), limitów na głębokość zapytania GraphQL i limitów na liczbę elementów w pojedynczym żądaniu batchowym. Rozsądna obrona to wielowarstwowy rate limiting — w API Gateway (gruby) oraz w aplikacji (precyzyjny, znający kontekst biznesowy).
API5:2023 Broken Function Level Authorization (BFLA)
BFLA to BOLA na poziomie funkcji zamiast obiektu. Endpoint dla administratora (np. DELETE /api/v1/admin/users/123) jest dostępny dla zwykłego użytkownika, bo backend nie sprawdza roli — zakłada, że skoro UI nie pokazuje guzika „usuń użytkownika”, to nikt nie wywoła endpointu.
PoC: aplikacja ma w dokumentacji OpenAPI sekcję /admin/*. Zalogowany użytkownik o roli customer wysyła żądanie DELETE /api/v1/admin/users/123 i operacja się powodzi. Backend autoryzował na podstawie wzorca w nazwie endpointu, ale nie sprawdził roli z tokena.
Test obejmuje próbę wywołania każdego endpointu administracyjnego z tokenem nieuprawnionego użytkownika. Burp Suite z Autorize lub własnym skryptem na bazie OpenAPI automatyzuje porównanie odpowiedzi 200 vs 403. Obrona to deklaratywna autoryzacja (np. dekoratory @RolesAllowed w warstwie aplikacji) i deny-by-default w API Gateway.
API6:2023 Unrestricted Access to Sensitive Business Flows
Szósta kategoria to relatywnie nowa pozycja na liście, która adresuje nadużycia logiki biznesowej. Nie chodzi o pojedynczy techniczny błąd, lecz o to, że krytyczne przepływy biznesowe nie mają zabezpieczeń przed automatyzacją — boty masowo wykupują bilety, masowo zakładają konta, masowo wykorzystują kody promocyjne.
PoC: scalper bot wykupuje wszystkie bilety na koncert w pierwszych dziesięciu sekundach sprzedaży, bo endpoint POST /api/v1/tickets/purchase nie ma CAPTCHA, nie ma fingerprintingu klienta, nie ma kolejki i nie wymaga uwierzytelnienia silniejszego niż token sesji.
Test wymaga modelowania zagrożeń specyficznego dla aplikacji — pentester musi zrozumieć, które przepływy biznesowe są atrakcyjne dla atakującego (kupon, polecenie, masowe wysyłki, scraping katalogu) i ocenić proporcję ochrony do ryzyka. Obrona to wielowarstwowa kombinacja CAPTCHA dla anonimowych użytkowników, device fingerprinting, kolejek z ograniczoną przepustowością i monitoringu anomalii zachowań.
API7:2023 Server Side Request Forgery (SSRF)
SSRF w API jest dziś jednym z najgroźniejszych technicznych ataków, szczególnie w architekturach chmurowych i mikroserwisowych. Występuje, gdy API przyjmuje URL od użytkownika (do pobrania webhooka, do importu pliku, do zewnętrznej integracji) i wykonuje żądanie do tego URL-a bez walidacji.
PoC: endpoint POST /api/v1/webhooks przyjmuje pole target_url. Atakujący ustawia target_url=http://169.254.169.254/latest/meta-data/iam/security-credentials/. Backend wykonuje żądanie do metadanych instancji EC2 i zwraca atakującemu poświadczenia IAM, które pozwalają na boczne ruchy w infrastrukturze AWS.
Test obejmuje sprawdzenie, czy API blokuje żądania do prywatnych zakresów IP (10.0.0.0/8, 192.168.0.0/16, 169.254.0.0/16), czy waliduje schemat URL (czy file://, gopher://, dict:// są blokowane), czy ma timeouty zapobiegające blind SSRF. Obrona wymaga allowlisty domen zamiast denylisty, walidacji po DNS resolution (żeby atakujący nie obszedł filtra przez własną domenę wskazującą na 127.0.0.1) oraz sieciowej segmentacji odcinającej serwer API od metadanych instancji tam, gdzie to możliwe.
API8:2023 Security Misconfiguration
Ósma kategoria jest workiem na wszystkie błędy konfiguracji — domyślne hasła, niezablokowane porty administracyjne, włączone tryby debug, brak nagłówków bezpieczeństwa, otwarte CORS, niezablokowane metody HTTP (TRACE, OPTIONS z verbose response), wyciekające informacje o stosie technologicznym w odpowiedziach błędów.
PoC: produkcyjne API ma włączone tryby DEBUG=true. Każdy błąd zwraca pełny stack trace z ścieżkami do plików, wersjami bibliotek i fragmentem kodu źródłowego. Atakujący widzi, że backend używa biblioteki w wersji podatnej na znane CVE i atakuje pod konkretną podatność.
Test obejmuje skanowanie nagłówków bezpieczeństwa (X-Content-Type-Options, Strict-Transport-Security, X-Frame-Options), próbę uzyskania verbose errors, sprawdzenie konfiguracji CORS (czy Access-Control-Allow-Origin: * współistnieje z Allow-Credentials: true) oraz fingerprinting wersji serwera i bibliotek. Obrona to hardening guides specyficzne dla stacka (np. CIS Benchmarks) oraz CI/CD pipeline, który blokuje deploy z włączonym debug.
API9:2023 Improper Inventory Management
Dziewiąta kategoria jest organizacyjna, nie czysto techniczna. Dotyczy braku świadomości, jakie API w ogóle istnieją w organizacji. Stare wersje (/api/v1/), środowiska testowe (/api/staging/), shadow IT (mikroserwis stworzony rok temu i zapomniany) są często wystawione w internecie z gorszymi zabezpieczeniami niż produkcyjna /api/v3/.
PoC: aktualne API to /api/v3/, dobrze chronione. Stara wersja /api/v1/ z 2019 roku nadal odpowiada, bo nikt jej nie wyłączył. W v1 nie było jeszcze BOLA fix z 2021 roku i atakujący eksfiltruje całą bazę użytkowników.
Test obejmuje wyszukiwanie nieoficjalnych endpointów (Wayback Machine, Google dorks, GitHub leaks, fuzzing typowych wzorców), porównanie listy znanych API z listą produkcyjnych endpointów w bramce API oraz weryfikację, że dokumentacja OpenAPI/Swagger jest aktualna i nie ujawnia endpointów niemających istnieć w produkcji. Obrona to centralny rejestr API (API catalog/inventory), polityka deprecate-and-remove zamiast deprecate-and-forget oraz zewnętrzne skany attack surface management.
API10:2023 Unsafe Consumption of APIs
Ostatnia kategoria odwraca perspektywę — nie chronisz swojego API przed atakującym, lecz chronisz się przed nieprzewidywalnym zachowaniem API trzecich stron, z których korzystasz. Atakujący nie atakuje Cię bezpośrednio, atakuje upstream-owego dostawcę i przez jego API trafia do Ciebie.
PoC: Twój backend ufa odpowiedziom z zewnętrznego API geolokalizacyjnego i wstawia je bez sanityzacji do bazy. Atakujący kompromituje dostawcę (lub MITM-uje połączenie, jeśli nie weryfikujesz TLS) i wstrzykuje payload, który u Ciebie spowoduje injection w warstwie raportowej.
Test obejmuje analizę zależności od API trzecich, weryfikację, że odpowiedzi są walidowane tak samo rygorystycznie jak input użytkownika, sprawdzenie pinningu TLS dla krytycznych integracji oraz weryfikację, że Twoje API nie podąża automatycznie za przekierowaniami do nieznanych domen. Obrona to traktowanie zewnętrznych API jako untrusted input — tak samo jak formularza od użytkownika.
Narzędzia do testowania API
Pentest API w 2026 roku opiera się na kombinacji kilku narzędzi, każde z innym profilem. Burp Suite Professional pozostaje warsztatem podstawowym — z rozszerzeniami Autorize (testy autoryzacji), JWT Editor (manipulacja JWT), ParamMiner (odkrywanie ukrytych parametrów) oraz natywnym wsparciem dla OpenAPI importu w wersjach 2024+ pokrywa większość scenariuszy manualnego pentestu.
Postman służy do eksploracji i powtarzalnych scenariuszy testowych, szczególnie gdy klient dostarcza gotową kolekcję. OWASP ZAP jest darmową alternatywą Burpa, bardzo silną w trybie automatycznego skanu i dobrze integrującą się z CI/CD. Schemathesis jest narzędziem property-based fuzzingu na bazie kontraktu OpenAPI lub GraphQL — generuje setki tysięcy żądań sprawdzających, czy implementacja API zachowuje się zgodnie ze specyfikacją (m.in. czy nie zwraca błędów 500 na poprawne wejście, czy waliduje typy). mitmproxy pomaga przy testach aplikacji mobilnych — przechwytuje ruch z urządzenia, pozwala podmieniać żądania w locie i jest skryptowalny w Pythonie.
Dla GraphQL osobnym narzędziem wartym uwagi jest InQL (rozszerzenie Burpa) oraz GraphQL Voyager do wizualizacji schematu. Dla gRPC — grpcurl plus własne skrypty na bazie pliku .proto. Żadne pojedyncze narzędzie nie zastąpi pentestera, ale dobrana kombinacja narzędzi pozwala pokryć rutynowe testy i uwolnić czas na manualne polowanie na nadużycia logiki biznesowej.
Checklist 12 kroków pentestu API
W praktyce nFlo i wielu innych zespołów pentest API przebiega według powtarzalnej checklisty, która zapewnia powtarzalność i kompletność. Poniższe dwanaście kroków to skrót procesu — pełny raport pentestu obejmuje wszystko z poniższej listy plus to, co specyficzne dla danej aplikacji.
- Zebranie specyfikacji — pozyskanie kontraktu OpenAPI/Swagger, kolekcji Postmana, opisu architektury, listy ról i uprawnień. Jeśli specyfikacja nie istnieje, pentester rekonstruuje ją na podstawie obserwacji ruchu.
- Rozpoznanie surface’u — enumeracja wszystkich endpointów (produkcyjnych, deprecated, testowych), identyfikacja wersji API i metod uwierzytelnienia. Krok adresuje ryzyko z API9.
- Test uwierzytelnienia — weryfikacja loginu, refresh tokenów, JWT, reset hasła, MFA. Krok adresuje API2.
- Test BOLA — dla każdego endpointu zwracającego obiekt, próba dostępu do obiektu należącego do innego użytkownika. Krok adresuje API1.
- Test BFLA — dla każdego endpointu administracyjnego, próba wywołania z tokenem zwykłego użytkownika. Krok adresuje API5.
- Test BOPLA — fuzzing pól w żądaniach (mass assignment) oraz inspekcja odpowiedzi (excessive data exposure). Krok adresuje API3.
- Test rate limitingu — sprawdzenie limitów per IP, użytkownik, klucz API, na endpoincie loginu, na endpointach kosztownych. Krok adresuje API4.
- Test SSRF — dla każdego endpointu przyjmującego URL, próba dostępu do prywatnej sieci i metadanych chmury. Krok adresuje API7.
- Test nadużyć biznesowych — modelowanie scenariuszy specyficznych dla domeny (scalping, account takeover, masowy onboarding). Krok adresuje API6.
- Test konfiguracji — nagłówki, CORS, verbose errors, dostępność konsol administracyjnych. Krok adresuje API8.
- Test integracji zewnętrznych — analiza zaufania do upstream-owych API. Krok adresuje API10.
- Raport z priorytetyzacją — opis każdego znaleziska z CVSS, PoC, rekomendacją naprawy i czasem trwania naprawy, z mapowaniem na OWASP API Top 10 i regulacje branżowe klienta.
Czas trwania pełnego pentestu zależy od liczby endpointów i złożoności logiki — typowo od pięciu do piętnastu dni roboczych dla API średniej wielkości.
Mapping na PCI DSS 4.0, NIS2 i DORA
OWASP API Top 10 nie jest sam w sobie wymaganiem regulacyjnym, ale jest naturalnym frameworkiem zakresowym dla wymagań, które regulacje stawiają. PCI DSS 4.0 (obowiązujące od marca 2025) w wymaganiu 6.4.3 wprost wymaga ochrony aplikacji webowych przed znanymi zagrożeniami publicznie udokumentowanymi — co w praktyce oznacza OWASP Top 10 i OWASP API Top 10. Wymaganie 11.4 wymaga testów penetracyjnych co najmniej raz w roku oraz po istotnych zmianach, a wytyczne wprost rekomendują, by pentest API był osobnym scope’em.
NIS2 (Dyrektywa UE 2022/2555) i polska transpozycja w nowelizacji UoKSC nakładają na podmioty kluczowe i ważne obowiązek zarządzania ryzykiem łańcucha dostaw ICT (art. 21). API jest dziś podstawowym wektorem zależności między dostawcami — od cloudowych dostawców usług po SaaS-y księgowe i CRM. Pentest API z mapowaniem na OWASP API Top 10 jest naturalnym sposobem na wykazanie due diligence wobec ryzyk API w łańcuchu dostaw oraz na spełnienie obowiązku okresowych testów odporności.
DORA (Rozporządzenie 2022/2554) dla sektora finansowego idzie dalej i w art. 24-27 wprowadza obowiązek testów odporności cyfrowej, w tym Threat-Led Penetration Testing (TLPT) dla największych podmiotów. TLPT, jak każdy zaawansowany pentest, obejmuje testy API jako jeden z głównych wektorów ataku — i tu mapowanie na OWASP API Top 10 jest standardem branżowym.
W praktyce raport pentestu API dla klienta podlegającego którejkolwiek z trzech regulacji powinien mieć osobną kolumnę „mapping” przy każdym znalezisku, wskazującą zarówno kategorię OWASP, jak i konkretny wymóg regulacyjny. To upraszcza pracę audytora i pokazuje, że pentest nie jest pojedynczym eventem, lecz częścią systematycznego programu zarządzania ryzykiem.
Podsumowanie
OWASP API Security Top 10 (2023) jest najlepszym dziś dostępnym, neutralnym technologicznie i darmowym frameworkiem do priorytetyzacji testów bezpieczeństwa API. Lista nie jest wyczerpującym katalogiem zagrożeń, ale dobrze odzwierciedla rzeczywisty rozkład problemów obserwowany w setkach pentestów. Trzy z dziesięciu kategorii dotyczą autoryzacji (BOLA, BFLA, BOPLA), kolejne dwie — uwierzytelnienia i nadużyć przepływów biznesowych. Razem pokazują, że największym ryzykiem API nie jest dziś klasyczne injection, lecz fundamentalne błędy w logice kontroli dostępu.
Dla zespołów developerskich lista jest mapą drogową — od czego zacząć, czego nie pominąć w code review, jakie testy włączyć do CI. Dla pentesterów jest zakresem bazowym, który należy rozszerzyć o specyfikę aplikacji. Dla działów compliance jest pomostem między techniką a regulacjami — pozwala wykazać, że pentest pokrył kategorie ryzyka uznane przez branżę za krytyczne, w sposób uznawany przez audytorów PCI DSS, NIS2 i DORA.
Potrzebujesz pentestu API zgodnego z OWASP API Top 10 oraz wymogami PCI DSS, NIS2 lub DORA? Sprawdź naszą usługę testów penetracyjnych — zespół nFlo realizuje pentesty REST, GraphQL i gRPC z pełnym mapowaniem na OWASP API Security Top 10 i regulacje branżowe klienta. Jeżeli interesuje Cię kompleksowe podejście do zgodności, audyt zgodności NIS2 obejmuje testy API jako jeden z elementów oceny ryzyka łańcucha dostaw ICT.
Powiązane pojęcia
Poznaj kluczowe terminy związane z tym artykułem w naszym słowniku cyberbezpieczeństwa:
- API — Application Programming Interface — kontrakt definiujący, jak komponenty oprogramowania komunikują się ze sobą.
- SQL Injection — Atak polegający na wstrzyknięciu fragmentu zapytania SQL do danych wejściowych aplikacji.
- Serwer — Maszyna lub proces obsługujący żądania od klientów w architekturze klient-serwer.
- SCA — Software Composition Analysis — analiza składu oprogramowania pod kątem znanych podatności w zależnościach.
- Szyfrowanie — Proces przekształcania danych do formy nieczytelnej bez znajomości klucza.
Sprawdź nasze usługi
Potrzebujesz wsparcia w zakresie cyberbezpieczeństwa? Sprawdź:
- Testy penetracyjne — identyfikacja podatności w infrastrukturze, aplikacjach i API
- Audyt zgodności NIS2 — kompletna ścieżka dostosowania do dyrektywy NIS2 i polskiej transpozycji
- SOC as a Service — całodobowy monitoring bezpieczeństwa
