API Penetration Testing — czym jest i jak działa?

TL;DR — czy API pentest to to samo co web app pentest?

Nie, choć są ze sobą powiązane. API Penetration Testing skupia się na warstwie interfejsów programistycznych (REST, GraphQL, gRPC, SOAP) — bezpośrednio na endpointach backendu, ignorując warstwę UI/HTML. Tradycyjny web application pentest celuje w HTML/JS warstwę przeglądarki i często pomija endpointy backendu używane przez aplikacje mobilne, SPA i integracje partnerów. OWASP od 2019 roku utrzymuje osobny API Security Top 10 (z drugą rewizją w 2023), ponieważ podatności API są fundamentalnie inne niż klasycznych aplikacji webowych — BOLA, mass assignment i broken function level authorization dominują w API, a XSS i CSRF są drugorzędne. Dla nowoczesnej aplikacji (SPA + REST API + mobile clients) potrzebujesz OBU testów.

API pentest vs web app pentest vs network pentest — porównanie

Cecha	API Penetration Testing	Web Application Pentest	Network / Infrastructure Pentest
Definicja	Test bezpieczeństwa endpointów API (REST, GraphQL, gRPC, SOAP)	Test bezpieczeństwa aplikacji webowej przez UI/przeglądarkę	Test bezpieczeństwa sieci, serwerów, urządzeń sieciowych
Scope	Endpointy backendu, business logic, autoryzacja na poziomie obiektu	Formularze HTML, JavaScript, session management	Porty, usługi sieciowe, AD, segmentacja VLAN, firewalle
Główne narzędzia	Burp Suite, Postman, OWASP ZAP, kiterunner, Akto, 42Crunch	Burp Suite, OWASP ZAP, sqlmap, Nikto, browser DevTools	Nmap, Metasploit, BloodHound, Responder, Impacket
Top podatności	BOLA, broken auth, mass assignment, BFLA, SSRF	XSS, SQLi, CSRF, broken access control, IDOR	Lateral movement, brak segmentacji, słabe poświadczenia AD, podatne usługi
Framework	OWASP API Security Top 10 (2023)	OWASP Top 10 (2021), OWASP ASVS	PTES, NIST SP 800-115, OSSTMM
Typowy czas	5-15 dni roboczych	7-20 dni roboczych	5-15 dni roboczych
Typowa cena (PL 2026)	15-200k PLN netto	20-150k PLN netto	25-150k PLN netto

W praktyce nowoczesne audyty łączą te warstwy. Pentest jednego B2B SaaS może obejmować: web app (panel admin), API (REST + GraphQL dla integracji partnerów), aplikacje mobilne (z reverse engineering APK/IPA) oraz infrastrukturę chmurową (AWS/Azure IAM i konfiguracja). Pełny audyt nflo zazwyczaj jest skomponowany z wielu modułów dopasowanych do architektury klienta.

Definicja API Penetration Testing

API Penetration Testing to kontrolowane, autoryzowane testy bezpieczeństwa interfejsów programistycznych aplikacji (Application Programming Interfaces) — REST, GraphQL, gRPC i SOAP — wykonywane przez wykwalifikowanego pentestera z perspektywy potencjalnego atakującego. Pentester ma za zadanie zidentyfikować podatności w warstwie API, które mogłyby pozwolić na nieautoryzowany dostęp do danych innych użytkowników, eskalację uprawnień, manipulację logiką biznesową, eksfiltrację wrażliwych informacji lub destabilizację usługi.

API pentest różni się od web app pentestu pod względem warstwy testowej (backend zamiast UI), discovery (dokumentacja Swagger/OpenAPI zamiast crawlowania HTML) i framework referencyjnego (OWASP API Security Top 10 zamiast klasycznego OWASP Top 10). Jest też różny od API security review lub API security audit, które zazwyczaj odnoszą się do statycznej analizy kodu i konfiguracji bez aktywnej eksploitacji — pentest to dynamic, hands-on testing z próbami realnej eksploitacji znalezionych podatności.

W kontekście compliance, API pentest jest często wymagany przez frameworki takie jak PCI DSS Req 6.6 (dla aplikacji obsługujących karty płatnicze), NIS2 Art. 21 (dla podmiotów kluczowych i ważnych w UE), DORA Art. 25 (dla podmiotów finansowych UE), HIPAA Security Rule (dla podmiotów medycznych w USA) i ISO/IEC 27001 A.14 (dla organizacji certyfikowanych).

OWASP API Security Top 10 (2023) — 10 kluczowych podatności

OWASP API Security Top 10 to industry-standard framework wydany pierwotnie w 2019 i zrewidowany w 2023. Każda organizacja wykonująca API pentest powinna pokrywać wszystkie 10 kategorii.

API1:2023 — Broken Object Level Authorization (BOLA)

Najczęstsza podatność API. Atakujący zmienia identyfikator obiektu w żądaniu (/api/users/123/orders → /api/users/124/orders) i otrzymuje dane innego użytkownika, ponieważ API NIE weryfikuje czy bieżący użytkownik ma uprawnienia do obiektu z danym ID. Występuje w 40-60% audytów API. Wykrywanie: dla każdego endpointu z ID — przetestuj z innym user_id, z incremented ID, z UUID innego tenanta. Mitigation: server-side checks per request, NIGDY nie polegaj na klient-side filtering.

API2:2023 — Broken Authentication

Słabości w mechanizmach uwierzytelniania: JWT bez weryfikacji podpisu lub z algorytmem none, brak rate-limitingu na login (password spray, credential stuffing), brakujący refresh token rotation, słabe MFA implementation, brakujące account lockout, dostępne password reset bypass.

API3:2023 — Broken Object Property Level Authorization

Łączy klasyczne mass assignment (klient wysyła pola których nie powinien móc edytować — PUT /api/users/me z isAdmin: true) i excessive data exposure (API zwraca wszystkie pola obiektu w response, wliczając wrażliwe jak password_hash, internal_notes, payment_method_token). Mitigation: explicit allow-lists pól dla input i output, NIGDY blacklist.

API4:2023 — Unrestricted Resource Consumption

Brak rate-limitów, brak quota, brak limitów rozmiaru request body, brak timeoutów na expensive operations. Pozwala na DoS, scrapowanie i nadużycia kosztowne (jeśli backend płaci za każde zapytanie do AI, API lub bazy). GraphQL jest szczególnie podatny przez nested queries — jedno zapytanie może wywołać tysiące resolverów.

API5:2023 — Broken Function Level Authorization (BFLA)

Użytkownik low-privilege wywołuje endpointy administracyjne. Klasyk: regular user wykonuje DELETE /api/admin/users/123 i API nie weryfikuje roli. Występuje gdy autoryzacja jest implementowana tylko po stronie frontend (admin panel ukrywa przycisk, ale endpoint jest dostępny dla każdego zalogowanego).

API6:2023 — Unrestricted Access to Sensitive Business Flows

NOWA kategoria w 2023. Automatyzacja krytycznych business flows: scalping (boty kupują wszystkie produkty w promocji), fraud (boty wykorzystują programy lojalnościowe), spam (boty masowo zakładają konta). Mitigation: device fingerprinting, behavioral biometrics, CAPTCHA na sensitive flows, rate limiting per device/user.

API7:2023 — Server Side Request Forgery (SSRF)

API pobiera URL podany przez klienta (np. webhook URL, image URL do download i resize) i wykonuje request bez walidacji. Atakujący wskazuje endpoint metadanych AWS (http://169.254.169.254/latest/meta-data/) lub wewnętrzne usługi (http://localhost:8080/admin) i może wyciągnąć IAM credentials lub atakować wewnętrzne API.

API8:2023 — Security Misconfiguration

Verbose error messages ujawniające stack trace i wersje frameworków, debug mode włączony w produkcji, brakujące security headers (HSTS, CSP, X-Content-Type-Options), domyślne credentials, niewyłączone HTTP methods (TRACE, OPTIONS unrestricted), niezabezpieczona dokumentacja Swagger w produkcji.

API9:2023 — Improper Inventory Management

Stare wersje API (v1, v2) wciąż produkcyjnie dostępne z znanymi podatnościami, niezdokumentowane shadow APIs używane wewnętrznie, brak inwentaryzacji environmentów (dev/staging dostępne z internetu z prod-like danymi). Wymaga API gateway z centralnym katalogiem i regularnym auditem.

API10:2023 — Unsafe Consumption of APIs

NOWA kategoria 2023 — bezpiecznie ufamy API trzecim stronom bez walidacji odpowiedzi. Jeśli twoje API wywołuje partnera i bezpośrednio renderuje wynik, podatność partnera może pozwolić na chain ataku (XSS, SSRF, deserialization). Mitigation: walidacja wszystkich odpowiedzi z third-party API jak inputu od użytkownika.

Metodyka API pentestingu (krok po kroku)

Standardowy pentest API składa się zazwyczaj z ośmiu faz, choć w praktyce iterują się one wielokrotnie.

1. Scope definition i pre-engagement

Ustalenie zakresu, ról testowych (zwykle 2-3 konta: anonimowy/guest, low-privilege user, admin), środowiska (production vs staging), okna czasowego, kontaktów emergency. Klient dostarcza dokumentację API (Swagger/OpenAPI specs, Postman collection lub HAR file z DevTools). Pentester wymaga dedykowanych test accounts oraz IP allow-listing aby nie kolidować z monitoringiem SOC.

2. API Discovery i mapowanie

Inwentaryzacja wszystkich endpointów. Źródła: oficjalna dokumentacja Swagger/OpenAPI, ruch przechwycony z aplikacji webowej (Burp Proxy), ruch z aplikacji mobilnej (mitmproxy + Frida do bypass certificate pinning), brute-force nazw endpointów (kiterunner z wordlistą 700k+ wzorców), GraphQL introspection query (jeśli dostępne), API gateway logs (jeśli klient udostępni).

3. Authentication & authorization testing

Testowanie wszystkich mechanizmów uwierzytelniania (Basic Auth, JWT, OAuth 2.0, OIDC, API keys, session cookies, mutual TLS) pod kątem: weak token generation, missing signature validation (JWT alg none), token reuse, timing attacks, brakujący rate-limit, password reset bypass, missing MFA enforcement na sensitive operations. Testowanie BOLA (API1) i BFLA (API5) — dla KAŻDEGO endpointu z ID lub admin role.

4. Business logic abuse

Najtrudniejsza i najcenniejsza faza. Tester analizuje business flows (rejestracja, zakup, refund, transfer środków, programy lojalnościowe) i szuka możliwości nadużyć: race conditions (dwa równoczesne refundy), negatywne kwoty, oszustwa kuponowe, manipulacja workflow state (pomijanie kroków), API6 sensitive business flows automation.

5. Parameter tampering i injection

Klasyczne injection ataki na endpointy API: SQL injection (sqlmap wspiera JSON/REST), NoSQL injection (MongoDB, CouchDB), command injection w endpointach z file processing, XXE w SOAP API, SSRF (API7), template injection w API z generowaniem dokumentów, deserialization attacks w API używających pickle/Java serialization.

6. Rate limiting i DoS testing

Testowanie limitów: czy login ma rate-limit (test password spray bez lockoutu), czy expensive endpoints mają quota, czy GraphQL ma query depth/complexity limits, czy są limity rozmiaru request body, czy są limity liczby równoległych requestów per user. API4 unrestricted resource consumption.

7. Configuration review

Sprawdzenie security misconfiguration (API8): verbose errors, debug mode, security headers, exposed Swagger w produkcji, default credentials, HTTP methods (TRACE, OPTIONS), CORS policy, exposed admin endpoints, exposed health/metrics endpoints (Prometheus, actuator), wersjowanie API (API9 — stare wersje dostępne).

8. Reporting i retest

Raport z findings (CVSS scoring, business impact, proof of concept, remediation), executive summary dla zarządu, technical detail dla developerów. Po naprawach przez klienta — retest (zwykle 30-50% ceny pierwotnej), weryfikujący że poprawki działają i nie wprowadziły regresji.

Narzędzia do API pentestingu

Standardowy stack 2026 łączy proxy do intercept/replay, klientów API do tworzenia precyzyjnych żądań, brute-forcery, fuzzery i automatyczne skanery.

• Burp Suite Professional — najczęściej używany proxy z bogatym ekosystemem rozszerzeń (JWT Editor, GraphQL Raider, Param Miner, Autorize do BOLA testów); de facto standard w pentest community.
• OWASP ZAP — open-source alternatywa Burpa, słabsza w fuzzing ale ma dobry API Scanner addon i wsparcie OpenAPI import.
• Postman / Insomnia / Bruno — klienci API do tworzenia kolekcji, dziedziczenia autoryzacji, automatyzacji scenariuszy. Bruno jako nowy gracz preferowany dla offline work (local file storage zamiast cloud sync).
• Akto.io — open-source platforma API security testingu, skanuje traffic mirror z bramy API i identyfikuje endpointy + automatycznie testuje OWASP API Top 10.
• APIsec / 42Crunch — komercyjne platformy enterprise z continuous API testing, policy enforcement i integracją CI/CD.
• mitmproxy — CLI/TUI proxy do przechwytywania ruchu mobilnej aplikacji, niezastąpione przy mapowaniu API klientów mobilnych.
• kiterunner — szybki brute-forcing endpointów API, wbudowana wordlista 700k+ wzorców pochodzących z publicznych Swagger/OpenAPI specs.
• arjun — wykrywacz ukrytych parametrów HTTP (czasem API akceptuje undokumentowane parametry, np. debug=1, admin=true).
• ffuf — uniwersalny fuzzer endpointów, parametrów i nagłówków, najszybszy w klasie.
• sqlmap — automatyczna eksploatacja SQL injection ze wsparciem dla JSON i REST endpointów.
• GraphQL Voyager + InQL + GraphQL Raider — narzędzia specyficzne dla GraphQL (introspection visualization, automatic query building, Burp extension).
• JWT.io + jwt_tool — manipulacja i ataki na tokeny JWT (alg confusion, key confusion, weak secret cracking).
• Frida — instrumentacja runtime aplikacji mobilnych, używana do bypass certificate pinning i hookowania funkcji w celu mapowania API mobilnych klientów.

REST vs GraphQL vs gRPC vs SOAP pentest — różnice

Każdy z czterech głównych stylów API ma swoją specyfikę i wymaga innego podejścia.

Aspekt	REST	GraphQL	gRPC	SOAP
Typowe podatności	BOLA, broken auth, mass assignment, IDOR	Nested query DoS, introspection leak, batching attack	TLS misconfiguration, brakujące auth na metodach, deserialization	XXE, WS-Security flaws, XPath/XSLT injection
Wymagania discovery	Swagger/OpenAPI, mapowanie z traffic	Introspection query, schema enumeration	.proto files, gRPC reflection (jeśli włączone)	WSDL files, UDDI
Specyficzne ataki	Parameter pollution, ID enumeration, race conditions	Query depth attacks, alias batching, query duplication	Method enumeration bez .proto, weak TLS	SOAPAction header manipulation, SAML assertion forgery
Główne narzędzia	Burp, Postman, ffuf, kiterunner	GraphQL Voyager, InQL, GraphQL Raider, BatchQL	grpcurl, gRPC Web Tools, BloodHound for gRPC	SoapUI, WSDigger, Burp WSDL
Trudność testowania	Niska-średnia	Wysoka (różnorodność queries)	Wysoka (binary protocol)	Średnia (legacy stack)
Częstotliwość w prod 2026	Bardzo wysoka	Wysoka (rosnąca)	Średnia (mikroserwisy)	Niska (legacy enterprise)

W praktyce nowoczesna aplikacja często łączy style — REST dla publicznego API, GraphQL dla wewnętrznego BFF (Backend-for-Frontend), gRPC dla komunikacji między mikroserwisami. Pełny audyt powinien pokryć każdą warstwę z odpowiednim toolingiem.

Typowe ataki i scenariusze

Poniżej 7 najczęstszych scenariuszy ataku obserwowanych w audytach API.

1. BOLA via incrementing IDs

Klasyk. Endpoint /api/orders/{id} zwraca zamówienia. Tester loguje się jako User A, wykonuje GET /api/orders/100 (swoje zamówienie), potem próbuje GET /api/orders/99, /api/orders/101 — jeśli widzi cudze zamówienia, podatność potwierdzona. Wariant z UUID: jeśli aplikacja używa UUID v4, BOLA wymaga znalezienia poprawnych ID innych użytkowników (np. z error messages, search endpointów, predictable UUID v1).

2. Mass assignment via overpost

Endpoint PUT /api/users/me akceptuje JSON. Pentester dodaje pole isAdmin: true lub accountBalance: 999999 do request body. Jeśli backend nie używa explicit allow-list pól (DTO), pola są zapisane do bazy. Identyfikacja: dodawaj nietypowe pola do każdego endpointu PUT/POST i sprawdzaj czy są persystowane.

3. JWT manipulation

Najczęstsze warianty: (a) alg none — zmiana alg: HS256 na alg: none i usunięcie podpisu (działa w bibliotekach bez striktnej walidacji), (b) algorytm confusion — wymiana RS256 na HS256 z public key jako secret, (c) weak secret — bruteforce JWT secret przez hashcat (jwt_tool ułatwia), (d) kid injection — manipulacja kid header żeby load arbitrary key file.

4. Broken auth via password spray

API loginu bez rate-limitingu. Atakujący próbuje jedno popularne hasło (Password123!, Welcome2026) na tysiącach username — minimalizuje lockout per-account. Detection: monitoring logowań po IP + behavioral anomaly. Mitigation: rate-limit per IP, geolokacja, MFA enforcement.

5. GraphQL introspection attack

Pierwsza rzecz w GraphQL pentest: czy introspection query ({ __schema { types { name } } }) jest włączona w produkcji? Jeśli tak, atakujący otrzymuje pełen schemat — wszystkie typy, pola, mutacje. Mitigation: wyłącz introspection w produkcji (introspection: false w Apollo Server).

6. Rate limit bypass via GraphQL batching

GraphQL pozwala na batching — wiele zapytań w jednym HTTP request. Atakujący wykonuje 1000× login w jednym requeście (każdy z innym hasłem) i omija rate-limit per-request. Mitigation: rate-limit per operation, nie per request; ograniczenie batch size.

7. IDOR via API parameter

Wariant BOLA, ale przez parameter zamiast path. Endpoint GET /api/notifications?user_id={id} lub POST /api/transfer { from_account: X, to_account: Y } — pentester zmienia user_id lub from_account na cudzy. Mitigation: NIGDY nie akceptuj user_id w request — wyciągnij z autoryzowanego JWT/session.

Compliance i wymogi regulacyjne dla API pentestingu

Pentest API jest często WYMAGANY przez frameworki compliance, nie jest tylko nice-to-have.

• PCI DSS Req 6.6 — aplikacje obsługujące dane kart płatniczych muszą mieć penetration test (manual lub WAF) co najmniej rocznie i po każdej istotnej zmianie. PCI DSS 4.0 (od 2024) jest jeszcze bardziej rygorystyczne i wymaga targeted risk analysis dla każdego API endpointu.
• NIS2 Art. 21 — Unia Europejska wymaga od podmiotów kluczowych i ważnych (essential and important entities) regularnych testów bezpieczeństwa, w tym API w skali odpowiedniej do ryzyka. Termin transpozycji 17 października 2024.
• DORA Art. 25 — Digital Operational Resilience Act dla podmiotów finansowych UE wymaga regularnych Threat-Led Penetration Testing (TLPT) co najmniej raz na 3 lata dla critical financial entities, zwykle obejmujące API. Obowiązuje od 17 stycznia 2025.
• HIPAA Security Rule § 164.308(a)(8) — periodic technical evaluation dla podmiotów medycznych w USA. W praktyce pentest co rok dla podmiotów obsługujących PHI przez API.
• ISO/IEC 27001:2022 A.8.29 — testing in development and acceptance. Audyt certyfikacyjny często sprawdza dowody pentestów aplikacji.
• RODO/GDPR Art. 32 — odpowiednie środki techniczne i organizacyjne; pentest jest najmocniejszym dowodem due diligence przy wycieku danych.
• ENISA Guidelines on API Security 2024 — wytyczne European Union Agency for Cybersecurity zalecające OWASP API Top 10 jako baseline.

W praktyce duże B2B SaaS w UE muszą pokryć co najmniej NIS2, ISO 27001 i RODO. Banki dodatkowo DORA i czasem PCI DSS. Podmioty medyczne — HIPAA jeśli operują w USA.

Jak nflo wykonuje API pentest

W nflo zazwyczaj prowadzimy audyt API jako część szerszego pakietu testy penetracyjne dopasowanego do architektury klienta. Standardowy projekt obejmuje:

• Pre-engagement workshop (1-2h) — ustalenie scope, ról, dokumentacji, krytycznych business flows do priorytetyzacji.
• API discovery z dostępnej dokumentacji Swagger/OpenAPI plus aktywne mapowanie ruchu z aplikacji webowych i mobilnych (jeśli istnieją).
• Pełne pokrycie OWASP API Security Top 10 (2023) — wszystkie 10 kategorii dla każdego endpointu.
• Manual business logic abuse testing — najcenniejsza faza, której automatyczne skanery NIE wykrywają.
• Raport finalny z CVSS scoring każdej podatności, business impact, proof of concept video/screen recordings i konkretnymi rekomendacjami remediation z code snippets.
• Retest po naprawach (zwykle 30-50% ceny pierwotnej) z weryfikacją że poprawki działają i nie wprowadziły regresji.

Sprawdź też powiązane usługi:

• Pentesty aplikacji webowych — gdy aplikacja ma UI/HTML do audytu obok API
• SOC 24/7 — wykrywanie ataków na API w produkcji w czasie rzeczywistym
• Incident Response — gdy podejrzewasz że twoje API zostało skompromitowane

Powiązane terminy

• Testy penetracyjne — szersza kategoria pentestów (web, API, network, mobile)
• Testy bezpieczeństwa API — pokrewny termin łączący pentest, DAST i SAST dla API
• OWASP Top 10 — klasyczny OWASP Top 10 dla aplikacji webowych
• API — definicja API jako konceptu
• API Security — szersze pojęcie bezpieczeństwa API (architektura, monitoring, defense-in-depth)
• DAST — Dynamic Application Security Testing
• SAST — Static Application Security Testing
• Bezpieczeństwo aplikacji — szersza dyscyplina application security

API Penetration Testing jest dziś jednym z najbardziej krytycznych komponentów programu bezpieczeństwa nowoczesnej organizacji. Niemal każda aplikacja produkcyjna 2026 opiera się na warstwie API — SPA, aplikacje mobilne, integracje partnerów, mikroserwisy, AI agents wykonujący function calls. Bez regularnego pentestu API ekspozycja danych klientów i ryzyko fraud rośnie wykładniczo wraz z liczbą endpointów. OWASP API Security Top 10 (2023) jest minimalnym baseline, a manual business logic testing przez doświadczonego pentestera pozostaje niezastąpiony — żaden automatyczny skaner DAST nie wykryje race condition w refund flow ani BFLA na ukrytym admin endpoint.