Testy penetracyjne API: sprawdź, czy Twoje API nie oddaje za dużo

API nie ma interfejsu użytkownika, więc błędy autoryzacji łatwo przeoczyć, a jednocześnie to przez API przepływają najbardziej wrażliwe dane. Testujemy REST, GraphQL i gRPC według OWASP API Security Top 10, gdzie na czele ryzyk stoi broken object level authorization, czyli możliwość sięgnięcia po cudze obiekty przez podmianę identyfikatora.

W odróżnieniu od aplikacji web nie ograniczają nas ekrany i przyciski. Pracujemy bezpośrednio na endpointach, sprawdzając każdy z nich pod kątem uprawnień, walidacji danych i ujawniania nadmiarowych informacji. Skaner widzi tu niewiele, bo nie zna kontekstu, czyli kto i do czego powinien mieć dostęp.

Dwie najczęstsze i najgroźniejsze klasy błędów w API to autoryzacja na poziomie obiektu i na poziomie funkcji. Pierwsza pozwala odczytać lub zmienić zasób należący do innego użytkownika, druga wywołać operację zarezerwowaną dla wyższej roli. Oba błędy są niewidoczne z zewnątrz i wymagają testu z perspektywy różnych kont.

Dlatego ustalamy z Tobą role i konta testowe, a następnie systematycznie sprawdzamy każdą granicę uprawnień. Potwierdzamy nie tylko, że dany endpoint istnieje, ale że poprawnie odrzuca żądanie, do którego konto nie ma prawa.

Specyfikacja OpenAPI albo gotowa kolekcja zapytań znacząco zwiększa pokrycie w tym samym czasie, bo nie musimy zgadywać, jakie endpointy i parametry istnieją. Im pełniejszy obraz powierzchni API, tym więcej realnych ścieżek ataku możemy zweryfikować zamiast szukać ich po omacku.

Jeśli dokumentacji nie ma, też przeprowadzimy test, mapując API na podstawie ruchu z aplikacji i analizy zachowania. Warto jednak wiedzieć, że dobra dokumentacja to nie tylko ułatwienie dla nas, ale wprost większa wartość testu dla Ciebie.

Raport opisuje każdą podatność z dowodem, oceną CVSS i konkretnym żądaniem odtwarzającym problem, żeby zespół deweloperski mógł go natychmiast zweryfikować. Dokładamy podsumowanie dla osób decyzyjnych z realnym wpływem na biznes oraz priorytety naprawcze ułożone według ryzyka.

Po naprawie wykonujemy retest i potwierdzamy zamknięcie luk. To istotne zwłaszcza dla API, które często stoi między aplikacją mobilną a backendem, bo pojedynczy błąd autoryzacji może odsłonić dane wszystkich użytkowników naraz.

API testujemy przed udostępnieniem go partnerom lub aplikacji klienckiej oraz po każdej zmianie kontraktu: nowych endpointach, zmianie modelu uprawnień czy migracji na nową wersję. Każda taka zmiana może otworzyć dostęp, którego wcześniej nie było.

Dla API wystawionego publicznie lub obsługującego dane osobowe i płatności rekomendujemy regularny cykl testów. Coraz częściej jest to także element wymagań regulacyjnych oraz warunek współpracy z większymi integratorami.