Bezpieczeństwo API: OWASP API Top 10 w praktyce

Aplikacje webowe i mobilne komunikują się dziś głównie przez API. To przesunęło środek ciężkości ataków: coraz rzadziej łamie się „stronę”, coraz częściej — interfejs, który ją zasila. Organizacja OWASP prowadzi osobne zestawienie API Security Top 10, bo API mają własną, specyficzną klasę błędów. Oto te, które w testach spotykamy najczęściej.

BOLA — najgroźniejsza i najczęstsza

Na szczycie listy stoi Broken Object Level Authorization (BOLA), znane też jako IDOR. Rzecz w tym, że API poprawnie uwierzytelnia użytkownika, ale nie sprawdza, czy dany obiekt należy do niego. Klasyczny przykład: żądanie GET /api/invoices/1043 zwraca fakturę, a zmiana numeru na 1044 zwraca cudzą — bo backend ufa identyfikatorowi z żądania.

Obrona: autoryzacja na poziomie każdego obiektu, po stronie serwera, dla każdego żądania. Nigdy nie zakładaj, że skoro użytkownik jest zalogowany, ma prawo do zasobu o podanym ID.

Broken authentication i nadmiar danych

Błędne uwierzytelnianie — słabe mechanizmy tokenów, brak limitów prób, źle zwalidowane JWT. API bywa „tylnymi drzwiami” pomijającymi kontrole obecne w interfejsie webowym.
Nadmierne ujawnianie danych — endpoint zwraca cały obiekt, a front pokazuje tylko część. Atakujący czyta surową odpowiedź i dostaje pola, których nie powinien widzieć (hasła, role, dane wewnętrzne). Filtruj dane po stronie serwera, nie w kliencie.

Brak limitów i błędna autoryzacja funkcji

Brak rate limitingu (Unrestricted Resource Consumption) — API bez limitów zaproszeń umożliwia enumerację, brute force i kosztowne nadużycia. Ogranicz tempo i wielkość żądań.
Broken Function Level Authorization — użytkownik zwykły wywołuje endpoint administracyjny, bo autoryzacja funkcji jest niespójna. Uprawnienia egzekwuj centralnie i domyślnie odmawiaj.

Jak podchodzić do bezpieczeństwa API

Autoryzacja przy każdym żądaniu i każdym obiekcie — to fundament, nie dodatek.
Pełna inwentaryzacja endpointów, w tym starych wersji i „shadow API” — nie ochronisz tego, o czym nie wiesz.
Walidacja wejścia i ścisłe schematy odpowiedzi (zwracaj tylko to, co potrzebne).
Logowanie i monitoring anomalii — nietypowa enumeracja identyfikatorów to sygnał ataku.

API to często najkrótsza droga do danych — dlatego testujemy je tak samo skrupulatnie jak resztę aplikacji. To również miejsce, gdzie łączą się wątki z priorytetyzacji podatności: liczy się kontekst i ekspozycja. Jeśli chcesz sprawdzić bezpieczeństwo swojego API, umów test.

Najpierw inwentaryzacja i kontrakt

Utrzymuj katalog API zawierający właściciela, środowisko, wersję, bazowy URL, typ danych, odbiorców i termin wycofania. Specyfikacja OpenAPI pomaga, ale porównaj ją z ruchem na gatewayu i logami, aby wykryć shadow oraz zombie API. Endpoint usunięty z dokumentacji może nadal odpowiadać.

Kontrakt powinien ograniczać pola wejścia i wyjścia. Odrzucaj nieznane właściwości tam, gdzie to bezpieczne, stosuj allowlistę pól aktualizowalnych i nie serializuj całego obiektu domenowego do odpowiedzi.

Autoryzacja obiektu, właściwości i funkcji

OWASP API Top 10 2023 rozdziela trzy poziomy problemu. BOLA dotyczy dostępu do konkretnego obiektu, Broken Object Property Level Authorization — pól obiektu, a Broken Function Level Authorization — całej funkcji. Sprawdzenie roli na routerze nie wystarczy, jeśli identyfikator zasobu pochodzi od użytkownika.

Twórz testy macierzowe: rola × właściciel × tenant × stan obiektu × operacja. Uruchamiaj je po każdej zmianie autoryzacji. Identyfikatory losowe zmniejszają możliwość zgadywania, ale nie zastępują decyzji dostępu po stronie serwera.

Zużycie zasobów i logika biznesowa

Rate limiting per adres IP nie chroni wszystkich scenariuszy. Limity powinny obejmować tożsamość, tenant, operację, koszt zapytania i zasób downstream. Dla eksportu, wyszukiwania i GraphQL kontroluj złożoność, rozmiar i czas.

Sensitive Business Flows wymagają reguł biznesowych: limitów tworzenia kont, rezerwacji, kuponów czy resetów. Bot wykonujący legalne żądania może nadużywać procesu bez klasycznej podatności technicznej.

Bezpieczne konsumowanie cudzych API

Odpowiedź z integracji zewnętrznej jest niezaufanym wejściem. Waliduj schemat, timeout, redirect, rozmiar i typ treści. Nie przekazuj jej komunikatów błędów bezpośrednio do klienta ani poleceń do wewnętrznego systemu. Stosuj odrębne poświadczenia i ogranicz egress.

Połącz te kontrole z bezpieczeństwem OAuth i testami kontraktowymi w CI.

Źródła: OWASP API Security Top 10 2023, OWASP API Security 2023 release notes.