Jak zabezpieczyć publiczne API przed automatycznym odtwarzaniem bazy danych

Publiczne API można odtworzyć bez włamania do serwera. Wystarczy legalnie wysyłać zapytania, zmieniać parametry filtrów i zapisywać odpowiedzi. Jeżeli endpoint zwraca pełne rekordy, przewidywalne identyfikatory i pozwala przechodzić po całym zbiorze, automat może w kilka godzin zbudować lokalną kopię katalogu produktów, bazy ogłoszeń, cennika, rejestru użytkowników albo danych analitycznych.

Nie istnieje pojedynczy nagłówek HTTP ani usługa WAF, która rozwiązuje ten problem. Ochrona przed automatycznym odtwarzaniem bazy danych wymaga ograniczenia wartości pojedynczej odpowiedzi, kontrolowania tempa pobierania i wykrywania zachowania charakterystycznego dla systematycznej enumeracji. Najważniejsza zasada brzmi: API powinno udostępniać użytkownikowi dane potrzebne do wykonania konkretnej operacji, a nie wygodny eksport całego zaplecza.

Najpierw ogranicz zakres danych, które da się wyliczyć

Najczęstszy błąd projektowy pojawia się wcześniej niż rate limiting. Endpoint jest po prostu zbyt hojny. Zwraca kilkadziesiąt pól, obsługuje sortowanie po każdym atrybucie, pozwala ustawić duży limit wyników i korzysta z kolejnych identyfikatorów: 10001, 10002, 10003. Dla automatu to niemal gotowy interfejs eksportowy.

Pierwszym krokiem powinien być przegląd powierzchni danych, czyli ustalenie, jakie informacje można pozyskać bez logowania, po zalogowaniu zwykłym kontem i z użyciem poszczególnych ról. Audyt trzeba wykonać z perspektywy klienta API, nie administratora bazy.

Dla każdego endpointu należy sprawdzić:

• ile rekordów można pobrać jednym żądaniem;
• czy istnieje maksymalna liczba stron lub głębokość paginacji;
• czy klient może sortować po identyfikatorze, dacie utworzenia lub dacie aktualizacji;
• czy filtry pozwalają dzielić zbiór na małe, rozłączne fragmenty;
• czy odpowiedź zawiera pola niewykorzystywane przez interfejs;
• czy rekord można pobrać po przewidywalnym identyfikatorze;
• czy komunikaty błędów ujawniają istnienie obiektu;
• czy endpoint podaje całkowitą liczbę wyników.

Szczególnie niebezpieczna jest kombinacja page, limit, sort=id i total_count. Bot od razu wie, ile stron musi pobrać, w jakiej kolejności oraz czy jego kopia jest kompletna. Samo zmniejszenie limitu ze 1000 do 100 rekordów niewiele zmienia. Zwiększa liczbę zapytań, ale nie usuwa możliwości przejścia przez cały zbiór.

Lepszym rozwiązaniem jest paginacja oparta na kursorze, przy czym kursor powinien być nieprzewidywalny, podpisany i ograniczony czasowo. Nie może być zwykłym identyfikatorem zakodowanym w Base64. Taki zapis nie chroni danych, ponieważ można go łatwo odwrócić lub modyfikować.

Dla typowego publicznego katalogu rozsądne wartości początkowe to:

• domyślnie 20–50 elementów w odpowiedzi;
• maksymalnie 100 elementów, jeżeli interfejs rzeczywiście tego wymaga;
• czas ważności kursora od 5 do 30 minut;
• brak swobodnego sortowania po technicznym identyfikatorze;
• osobny endpoint eksportowy tylko dla uprawnionych klientów;
• ograniczenie maksymalnej głębokości przeglądania, jeżeli pełny katalog nie musi być dostępny.

Nie zawsze da się zablokować przejście po wszystkich rekordach. W porównywarce ofert, publicznym rejestrze albo katalogu nieruchomości użytkownik może mieć uzasadnione prawo do przeglądania całego zbioru. W takim przypadku celem nie jest niemożliwa do zagwarantowania blokada, lecz podniesienie kosztu masowego pobierania, wykrycie procesu i ograniczenie wartości skopiowanych danych.

Trzeba również zmniejszyć odpowiedzi do pól faktycznie potrzebnych klientowi. Lista produktów może zwracać nazwę, cenę, miniaturę i status dostępności. Pełny opis, historię zmian, parametry logistyczne oraz identyfikatory integracyjne należy podawać dopiero w widoku szczegółowym, po przejściu osobnej kontroli uprawnień.

To rozwiązanie ma niedogodność: bardziej granularne API generuje więcej zapytań. Rośnie ruch między frontendem a backendem, komplikują się cache i obserwowalność. Mimo to jest bezpieczniejsze niż jeden endpoint zwracający kompletny rekord za każdym razem.

Rate limiting musi uwzględniać koszt, tożsamość i wzorzec ruchu

Prosty limit „100 żądań na minutę z jednego IP” zatrzyma źle napisany skrypt, ale nie profesjonalnego scrapera. Adresy można rotować przez chmurę, sieci komórkowe, usługi proxy i zainfekowane urządzenia. Legalni użytkownicy za firmowym NAT-em mogą natomiast współdzielić jeden adres i zostać zablokowani mimo normalnego ruchu.

Rate limiting powinien działać równocześnie na kilku poziomach:

• adres IP lub prefiks sieci;
• konto użytkownika;
• klucz API;
• token sesji;
• urządzenie lub stabilny identyfikator klienta;
• organizacja korzystająca z API;
• konkretny endpoint;
• kategoria kosztu zapytania.

Nie każde żądanie kosztuje tyle samo. Pobranie pojedynczego publicznego profilu może być tanie, natomiast zapytanie z wieloma filtrami, sortowaniem i agregacją potrafi obciążyć bazę kilkadziesiąt razy mocniej. Dlatego warto wdrożyć budżet punktowy zamiast liczenia samych żądań.

Przykładowy model startowy:

• pobranie pojedynczego obiektu: 1 punkt;
• pobranie listy do 50 elementów: 3 punkty;
• wyszukiwanie pełnotekstowe: 5 punktów;
• zapytanie z agregacją: 10 punktów;
• eksport lub ciężki raport: 50–100 punktów.

Dla publicznego endpointu można rozpocząć od budżetu rzędu 60–120 punktów na minutę na IP oraz 500–1500 punktów na godzinę. Dla zalogowanego użytkownika sensowny punkt wyjścia to 300–600 punktów na minutę, o ile profil produktu rzeczywiście wymaga intensywnego odpytywania. Są to wartości wdrożeniowe do testów, a nie uniwersalna norma. Trzeba je dopasować do rzeczywistego rozkładu ruchu z okresu co najmniej 14–30 dni.

Praktyczny limit powinien korzystać z mechanizmu token bucket albo sliding window, ponieważ oba modele pozwalają obsłużyć krótki, naturalny skok ruchu bez otwierania drogi do długotrwałego pobierania. Sztywne okna czasowe bywają łatwe do obchodzenia: automat wykonuje serię zapytań tuż przed końcem minuty i kolejną tuż po jej rozpoczęciu.

Po przekroczeniu limitu serwer powinien zwracać kod 429 Too Many Requests oraz nagłówek Retry-After. Nie należy odpowiadać błędem 500, ponieważ utrudnia to diagnozę i może sprowokować klienta do agresywnych ponowień.

Samo ograniczenie liczby żądań nadal nie wystarcza. Trzeba analizować wzorzec dostępu. Typowe sygnały odtwarzania bazy to:

• przechodzenie po stronach bez przerw i bez powrotów;
• odpytywanie identyfikatorów rosnąco lub malejąco;
• pobieranie niemal wyłącznie rekordów szczegółowych;
• systematyczne zmienianie zakresów dat;
• wysoki udział odpowiedzi 404;
• powtarzalne zapytania co równy interwał;
• brak pobierania zasobów typowych dla przeglądarki;
• równoległe sesje wykonujące różne fragmenty tego samego zadania;
• bardzo wysoki odsetek unikalnych rekordów bez powtórnych wizyt.

Dobry system nie blokuje użytkownika po jednym nietypowym żądaniu. Nadaje zdarzeniom punkty ryzyka, a reakcję stopniuje. Przykładowo wynik 40 może obniżać limit, 60 uruchamiać dodatkowe uwierzytelnienie, a 80 czasowo blokować dostęp. Progi powinny wynikać z danych produkcyjnych, bo nadmiernie agresywna konfiguracja uderza w aplikacje mobilne, integracje partnerskie i narzędzia dostępności.

CAPTCHA nadaje się głównie do ochrony operacji wykonywanych przez człowieka, takich jak rejestracja, wysłanie formularza czy rozpoczęcie kosztownego wyszukiwania. Wstawianie CAPTCHA przed każdym odczytem API jest niewygodne, trudne dla aplikacji mobilnych i problematyczne z punktu widzenia dostępności. Nie jest też odpowiednim zabezpieczeniem dla legalnych integracji maszynowych.

Wykrywanie odtwarzania bazy wymaga telemetrii i kontrolowanej reakcji

Bez szczegółowych logów administrator widzi jedynie wzrost liczby zapytań. To za mało, aby odróżnić udaną kampanię marketingową od automatu budującego kopię danych. Każde żądanie powinno pozostawić ślad pozwalający połączyć aktywność w jedną sekwencję.

W logach warto zapisywać co najmniej:

• identyfikator konta, organizacji i klucza API;
• skrót tokenu sesji zamiast pełnego tokenu;
• adres IP oraz prefiks sieci;
• endpoint, metodę i znormalizowany zestaw parametrów;
• liczbę zwróconych rekordów;
• zakres lub skrót identyfikatorów obiektów;
• kod odpowiedzi i czas wykonania;
• koszt punktowy zapytania;
• identyfikator urządzenia lub klienta;
• wynik oceny ryzyka;
• decyzję systemu: przepuszczenie, ograniczenie, wyzwanie lub blokadę.

Pełne logowanie treści odpowiedzi zwykle nie jest potrzebne i może tworzyć dodatkowe ryzyko związane z RODO, retencją danych oraz dostępem administratorów. W większości wdrożeń wystarczą metadane, skróty i zakresy identyfikatorów. Okres przechowywania trzeba powiązać z celem: dla analizy nadużyć często stosuje się 30–90 dni, ale ostateczny termin powinien wynikać z polityki retencji, oceny ryzyka i podstawy prawnej organizacji.

Najbardziej użyteczne alerty nie opierają się na samej liczbie żądań. Powinny wykrywać pokrycie zbioru. Jeżeli jedna tożsamość pobrała 80 procent aktywnych rekordów w ciągu sześciu godzin, jest to znacznie mocniejszy sygnał niż 10 tysięcy powtórzeń tych samych pięciu zasobów.

Warto mierzyć między innymi:

• procent unikalnych rekordów pobranych w ciągu godziny i doby;
• tempo przyrostu nowych identyfikatorów;
• udział całego katalogu odczytany przez konto;
• liczbę kolejnych stron odwiedzonych bez przerwy;
• podobieństwo aktywności między różnymi adresami IP;
• powtarzalność parametrów i nagłówków;
• odchylenie od historycznego profilu klienta.

Przy szczególnie wartościowych danych można zastosować rekordy pułapkowe lub znaczniki identyfikujące źródło wycieku. Muszą być zaprojektowane ostrożnie. Fałszywa oferta, fikcyjna osoba albo błędna cena mogą trafić do użytkownika i naruszyć wiarygodność systemu. Bezpieczniejsze są niewidoczne dla odbiorcy warianty kolejności, unikalne znaczniki techniczne lub kontrolowane różnice w danych udostępnianych partnerom.

Reakcja powinna następować etapami:

1. obniżenie budżetu zapytań;
2. skrócenie maksymalnej strony wyników;
3. wyłączenie kosztownych filtrów;
4. żądanie ponownego uwierzytelnienia;
5. tymczasowe zablokowanie tokenu;
6. weryfikacja właściciela integracji;
7. trwałe odebranie klucza i analiza incydentu.

Natychmiastowa blokada po pierwszym alercie często jest błędem. Integracja klienta mogła wejść w pętlę po awarii, a aplikacja mobilna mogła wielokrotnie ponawiać żądania przez niestabilne połączenie. Z drugiej strony czekanie na stuprocentową pewność pozwala scraperowi skończyć pracę. W praktyce najlepiej sprawdza się szybkie ograniczenie przepustowości, które zmniejsza skalę szkody, ale pozostawia czas na ocenę zdarzenia.

Warstwa WAF, na przykład Cloudflare, AWS WAF, Azure Web Application Firewall lub rozwiązanie działające przy Nginx, pomaga filtrować ruch, lecz nie zna kontekstu biznesowego. Nie wie, czy pobranie 20 tysięcy ofert przez konkretną organizację jest normalną synchronizacją, czy nadużyciem. Tę decyzję powinien podejmować backend albo osobna warstwa zarządzania API, korzystająca z danych o kontach, rolach i umowach.

Przy projektowaniu takiej architektury pomocne bywają materiały techniczne publikowane na aiqo.pl, zwłaszcza gdy zabezpieczenia API trzeba połączyć z obserwowalnością, analizą zachowania klientów i decyzjami podejmowanymi po stronie aplikacji, a nie wyłącznie na brzegu sieci.

FAQ

Czy można całkowicie uniemożliwić skopiowanie danych dostępnych publicznie?
Nie. Jeżeli użytkownik może zobaczyć dane, automat również może je zapisać. Można natomiast ograniczyć tempo, zakres i opłacalność kopiowania, szybciej wykrywać proces oraz zmniejszyć liczbę ujawnianych pól.

Czy ukrycie endpointu albo zmiana jego adresu wystarczy?
Nie. Adresy API można znaleźć w kodzie aplikacji, logach przeglądarki i ruchu sieciowym. Ukryty endpoint bez kontroli dostępu pozostaje publicznym endpointem.

Czy UUID zabezpiecza rekordy przed enumeracją?
Utrudnia zgadywanie identyfikatorów, ale nie zatrzymuje pobierania list, wyszukiwania ani przechodzenia po kursorach. UUID jest warstwą pomocniczą, a nie mechanizmem kontroli dostępu.

Czy każde publiczne API powinno wymagać klucza?
Nie zawsze, ale klucz ułatwia przypisanie ruchu do klienta, nadawanie limitów i odbieranie dostępu. Trzeba pamiętać, że klucz umieszczony w aplikacji frontendowej nie jest sekretem i może zostać skopiowany.

Jaki limit zapytań ustawić na początku?
Najpierw należy zmierzyć legalny ruch. Jako konfigurację testową można przyjąć 60–120 punktów na minutę dla ruchu anonimowego i kilka razy więcej dla zweryfikowanego klienta. Po 14–30 dniach trzeba skorygować progi na podstawie percentyli, liczby fałszywych alarmów i kosztu zapytań.

Czy robots.txt chroni API przed scraperami?
Nie. Plik robots.txt jest dobrowolną instrukcją dla zgodnych robotów indeksujących. Nie stanowi kontroli dostępu i nie zatrzymuje złośliwego klienta.

Czy blokowanie centrów danych rozwiązuje problem?
Tylko częściowo. Ograniczy najprostsze boty, ale może również zablokować legalne integracje. Bardziej zaawansowane systemy korzystają z adresów domowych i komórkowych, dlatego reputacja IP powinna być jednym z sygnałów, a nie jedyną podstawą decyzji.

Pierwsza decyzja powinna dotyczyć nie zakupu kolejnego narzędzia, lecz najbardziej hojnego endpointu listującego dane. Trzeba sprawdzić, ile unikalnych rekordów anonimowy klient może pobrać w ciągu godziny, czy może sortować po identyfikatorze i czy odpowiedź zawiera niepotrzebne pola. Jeżeli da się przejść po całej bazie za pomocą przewidywalnej paginacji, ten błąd należy usunąć przed konfiguracją CAPTCHA, WAF-u i zaawansowanego scoringu ryzyka.